Block chain block synchronization method and device, computer equipment and storage medium

Abstract

The invention relates to a block chain block synchronization method and device, computer equipment, a storage medium and a computer program product. The method comprises the following steps: determining to-be-synchronized block information; based on the to-be-synchronized block information, determining consensus nodes of which blocks are respectively matched with the to-be-synchronized block information; generating a fragment push request according to the to-be-synchronized block information, the node number of the consensus nodes and the block fragment index information of each consensus node; sending a fragment push request to each consensus node, and indicating the consensus node to return specified fragment data determined based on the to-be-synchronized block information; the specified fragment data is fragment data which is matched with block fragment index information in the received fragment push request in each piece of fragment data and is obtained by performing fragment division on included blocks according to the node number by the received consensus node; and according to the specified fragment data returned by each consensus node, carrying out block synchronization on the to-be-synchronized node. By adopting the method, the block synchronization efficiency can be improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a blockchain block synchronization method, apparatus, computer equipment, storage medium and computer program product. Background Art

[0002] With the development of computer technology, blockchain has attracted more and more attention and applications due to its characteristics of decentralization, information immutability, and autonomy. In order to enable each blockchain node on the blockchain to participate in the normal consensus process, it is necessary to synchronize the blocks of the nodes on the blockchain whose block height lags behind the latest block height in the blockchain network to ensure the timely update of the consensus nodes. However, the current block synchronization efficiency of nodes in the blockchain network is low. Summary of the invention

[0003] Based on this, it is necessary to provide a blockchain block synchronization method, device, computer equipment, computer-readable storage medium and computer program product that can improve the efficiency of block synchronization in response to the above-mentioned technical problems.

[0004] In a first aspect, the present application provides a blockchain block synchronization method. The method comprises:

[0005] Determine the block information to be synchronized of the node to be synchronized in the blockchain network;

[0006] Determine each consensus node from the blockchain network based on the block information to be synchronized; the blocks included in each consensus node are matched with the block information to be synchronized;

[0007] Generate a shard push request for each consensus node according to the block information to be synchronized, the number of consensus nodes, and the block shard index information of each consensus node;

[0008] Sending a shard push request for each configuration to each consensus node; the shard push request is used to instruct the receiving consensus node to return the specified shard data in the block to be synchronized determined based on the block information to be synchronized; the specified shard data is the shard data in each shard data that matches the block shard index information in the received shard push request; the shard data is obtained by the receiving consensus node dividing the block to be synchronized into shards according to the number of nodes;

[0009] According to the specified shard data returned by each consensus node, block synchronization is performed for the node to be synchronized.

[0010] In a second aspect, the present application also provides a blockchain block synchronization device. The device includes:

[0011] An information acquisition module is used to determine the block information to be synchronized of the node to be synchronized in the blockchain network;

[0012] A consensus node determination module is used to determine each consensus node from the blockchain network based on the block information to be synchronized; the blocks included in each consensus node are matched with the block information to be synchronized respectively;

[0013] The shard push request generation module is used to generate shard push requests configured for each consensus node according to the block information to be synchronized, the number of consensus nodes, and the block shard index information of each consensus node;

[0014] The shard data acquisition module is used to send the configured shard push request to each consensus node respectively; the shard push request is used to instruct the receiving consensus node to return the specified shard data in the block to be synchronized determined based on the block information to be synchronized; the specified shard data is the shard data in each shard data that matches the block shard index information in the received shard push request; the shard data is obtained by the receiving consensus node dividing the block to be synchronized into shards according to the number of nodes;

[0015] The block update module is used to synchronize blocks for the nodes to be synchronized according to the specified shard data returned by each consensus node.

[0016] In a third aspect, the present application further provides a computer device. The computer device includes a memory and a processor, the memory stores a computer program, and the processor implements the steps of the above blockchain block synchronization method when executing the computer program.

[0017] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, which implements the steps of the above blockchain block synchronization method when executed by a processor.

[0018] In a fifth aspect, the present application also provides a computer program product. The computer program product includes a computer program, which implements the steps of the above blockchain block synchronization method when executed by a processor.

[0019] The above-mentioned blockchain block synchronization method, device, computer equipment, storage medium and computer program product determine the block information to be synchronized of the node to be synchronized in the blockchain network, determine the blocks included in the blockchain network based on the block information to be synchronized, and match the block information to be synchronized for each consensus node respectively. According to the block information to be synchronized, the number of consensus nodes and the block shard index information of each consensus node, generate a shard push request configured for each consensus node. After the shard push request is sent to each consensus node, it is used to instruct each consensus node to return the specified shard data in the block to be synchronized determined based on the block information to be synchronized. The specified shard data is the shard data in each shard data that matches the block shard index information in the received shard push request. The receiving consensus node divides the included block to be synchronized into shards according to the number of nodes to obtain the shard data. According to the specified shard data returned by each consensus node, block synchronization is performed for the node to be synchronized. During the blockchain block synchronization process, each consensus node is determined based on the to-be-synchronized block information of the to-be-synchronized node, and a shard push request configured for each consensus node is generated according to the to-be-synchronized block information, the number of consensus nodes, and the block shard index information of each consensus node. After the shard push request is sent to each consensus node, it is used to instruct the receiving consensus node to return the specified shard data based on the shard push request, so that block synchronization can be performed according to the specified shard data returned by each consensus node, and multiple consensus nodes can be effectively scheduled for block synchronization, thereby improving the synchronization efficiency of blocks in the blockchain.

[0020] In a sixth aspect, the present application provides a blockchain block synchronization method. The method comprises:

[0021] Receive a shard push request sent by a node to be synchronized in the blockchain network; the shard push request includes information about the block to be synchronized for the node to be synchronized, the number of consensus nodes, and the block shard index information;

[0022] Determine the blocks to be synchronized for the nodes to be synchronized based on the information of the blocks to be synchronized, and divide the blocks to be synchronized into shards according to the number of nodes to obtain data of each shard;

[0023] Determine the designated shard data matching the block shard index information from each shard data;

[0024] Push the specified shard data to the node to be synchronized; the specified shard data is used to instruct the node to be synchronized to synchronize blocks based on the specified shard data.

[0025] In a seventh aspect, the present application also provides a blockchain block synchronization device. The device comprises:

[0026] A shard push request receiving module, used to receive a shard push request sent by a node to be synchronized in the blockchain network; the shard push request includes information about the block to be synchronized for the node to be synchronized, the number of consensus nodes, and the block shard index information;

[0027] A shard data determination module is used to determine the to-be-synchronized blocks for the to-be-synchronized nodes based on the to-be-synchronized blocks information, and divide the to-be-synchronized blocks into shards according to the number of nodes to obtain data for each shard;

[0028] A designated shard data determination module is used to determine the designated shard data matching the block shard index information from each shard data;

[0029] The specified shard data push module is used to push the specified shard data to the node to be synchronized; the specified shard data is used to instruct the node to be synchronized to perform block synchronization based on the specified shard data.

[0030] In an eighth aspect, the present application further provides a computer device. The computer device includes a memory and a processor, the memory stores a computer program, and the processor implements the steps of the above blockchain block synchronization method when executing the computer program.

[0031] In a ninth aspect, the present application further provides a computer-readable storage medium, wherein a computer program is stored thereon, and when the computer program is executed by a processor, the steps of the above blockchain block synchronization method are implemented.

[0032] In a tenth aspect, the present application also provides a computer program product. The computer program product includes a computer program, which implements the steps of the above blockchain block synchronization method when executed by a processor.

[0033] The above-mentioned blockchain block synchronization method receives a shard push request sent by a node to be synchronized in a blockchain network, which includes determining the block information to be synchronized for the node to be synchronized, the number of nodes of the consensus node, and the block shard index information, determining the block to be synchronized for the node to be synchronized based on the block information to be synchronized, and dividing the block to be synchronized into shards according to the number of nodes, obtaining each shard data, determining the designated shard data matching the block shard index information from each shard data, and pushing the designated shard data to the node to be synchronized to instruct the node to be synchronized to perform block synchronization based on the designated shard data. In the process of blockchain block synchronization, the designated shard data is pushed to the node to be synchronized based on the received shard push request, so that the node to be synchronized can perform block synchronization according to the designated shard data returned by each consensus node, and multiple consensus nodes can be effectively scheduled for block synchronization, thereby improving the synchronization efficiency of blocks in the blockchain. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Figure 1 This is an application environment diagram of a blockchain block synchronization method in one embodiment;

[0035] Figure 2 A diagram of an application environment of a blockchain block synchronization method in a data sharing system in one embodiment;

[0036] Figure 3 A schematic diagram of the structure of a blockchain in one embodiment;

[0037] Figure 4 Schematic diagram of a process of generating a new block in one embodiment;

[0038] Figure 5 A flowchart of a blockchain block synchronization method in one embodiment;

[0039] Figure 6 It is an interactive sequence diagram of a blockchain block synchronization method in one embodiment;

[0040] Figure 7 A flowchart of a blockchain block synchronization method in another embodiment;

[0041] Figure 8 A flowchart of a blockchain block synchronization method in another embodiment;

[0042] Fig. 9 A schematic diagram of a block sharding structure in one embodiment;

[0043] Fig.10 This is a block synchronization process diagram of the traditional method;

[0044] Fig.11 A schematic diagram of a multi-node synchronization process of a blockchain block synchronization method in one embodiment;

[0045] Fig.12 A schematic diagram of processing shard data in one embodiment;

[0046] Fig.13 A schematic diagram of a data reorganization structure in one embodiment;

[0047] Fig.14 A flowchart of a blockchain block synchronization method in another embodiment;

[0048] Fig.15 is a block diagram of the internal structure of a node manager in one embodiment;

[0049] Fig.16 A schematic diagram of a process for processing a received node heartbeat message in an embodiment;

[0050] Fig.17A schematic diagram of a process of maintaining a node list by a network stability analyzer in one embodiment;

[0051] Fig.18 A schematic diagram of a process of maintaining a node list by a network stability analyzer in another embodiment;

[0052] Fig.19 A schematic diagram of a process of selecting a node by a node selector in one embodiment;

[0053] Fig. 20 It is a structural block diagram of a blockchain block synchronization device in one embodiment;

[0054] Fig.21 It is a structural block diagram of a blockchain block synchronization device in another embodiment;

[0055] Fig. 22 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0056] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0057] Before going into detail, some terms involved in this application are explained first.

[0058] Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc. Blockchain is essentially a decentralized database, a string of data blocks generated by cryptographic methods. Each data block contains a batch of network transaction information, which is used to verify the validity of its information (anti-counterfeiting) and generate the next block. Blockchain can include the underlying blockchain platform (i.e. the underlying chain), the platform product service layer, and the application service layer.

[0059] The underlying blockchain platform can include processing modules such as user management, basic services, smart contracts, and operational detection. Among them, the user management module is responsible for the identity information management of all blockchain participants, including maintaining public and private key generation (account management), key management, and the maintenance of the correspondence between the user's real identity and the blockchain address (authority management), etc., and, under authorization, manages and audits the transactions of certain real identities and provides risk control rule configuration (risk control audit); the basic service module is deployed on all blockchain node devices to verify the validity of business requests, and records valid requests to storage after consensus is reached. For a new business request, the basic service first performs interface adaptation analysis and authentication processing (interface adaptation), and then encrypts the business information through the consensus algorithm (consensus management). The smart contract module is responsible for the registration and issuance of contracts, as well as contract triggering and contract execution. Developers can define the contract logic in a programming language and publish it to the blockchain (contract registration). According to the logic of the contract terms, the key or other events are called to trigger the execution and complete the contract logic. It also provides the function of contract upgrade and cancellation. The operation detection module is mainly responsible for the deployment, configuration modification, contract setting, cloud adaptation and real-time status visualization output of the product during the product release process, such as alarm, network status detection, node equipment health status detection, etc.

[0060] The platform product service layer provides the basic capabilities and implementation framework of typical applications. Developers can superimpose business features based on these basic capabilities to complete the blockchain implementation of business logic. The application service layer provides application services based on blockchain solutions for business participants to use.

[0061] The blockchain block synchronization method provided in the embodiment of the present application can be applied to Figure 1 In the application environment shown, Figure 1The application environment shown includes a node to be synchronized 102 and multiple consensus nodes 104 in a blockchain network, wherein the node to be synchronized 102 communicates with each consensus node 104 through a network. The data storage system can store data that the node to be synchronized 102 needs to process. The data storage system can be integrated on the node to be synchronized 102, or placed on a cloud or other server. The node to be synchronized 102 and the consensus node 104 can be any blockchain node in the blockchain network. For each blockchain node in the blockchain network, when any blockchain node needs to perform a block update, the blockchain node is the node to be synchronized 102. Among them, the blockchain node that needs to perform a block update can specifically include a new node, which can be a node newly added to the blockchain network, or a node that currently exists in the blockchain network but whose block height does not reach the latest block height in the blockchain network, or a node that currently exists in the blockchain network and is back online after being offline. The consensus node 104 can be a blockchain node in the blockchain network for receiving a shard push request from the node to be synchronized 102, and returning the specified shard data based on the shard push request.

[0062] When specifically implementing blockchain block synchronization, the node to be synchronized 102 can independently complete its own block synchronization, or other blockchain nodes in the blockchain network, except the node to be synchronized 102, can assist the node to be synchronized 102 in completing block synchronization when determining that the node to be synchronized 102 exists in the blockchain network. Specifically, the node 102 to be synchronized determines its own block information to be synchronized, and determines from the blockchain network based on the block information to be synchronized that the blocks included in each of the consensus nodes 104 match the block information to be synchronized, and generates a shard push request configured for each consensus node 104 according to the block information to be synchronized, the number of nodes of the consensus node 104, and the block shard index information of each consensus node 104. After the shard push request is sent to each consensus node 104, it is used to instruct each consensus node 104 to return the specified shard data in the block to be synchronized determined based on the block information to be synchronized. The specified shard data is the shard data in each shard data that matches the block shard index information in the received shard push request. The receiving consensus node 104 divides the included block to be synchronized into shards according to the number of nodes to obtain the shard data, and performs block synchronization for the node 102 to be synchronized according to the specified shard data returned by each consensus node 104.

[0063] The blockchain block synchronization method provided in this application can be applied to Figure 1In the application environment shown. When specifically implementing blockchain block synchronization, the consensus node 104 can receive a shard push request sent by the node to be synchronized 102 in the blockchain network, the shard push request includes determining the block information to be synchronized for the node to be synchronized 102, the number of nodes of the consensus node 104, and the block shard index information, determining the block to be synchronized for the node to be synchronized 102 based on the block information to be synchronized, and dividing the block to be synchronized into shards according to the number of nodes, obtaining each shard data, determining the specified shard data matching the block shard index information from each shard data, pushing the specified shard data to the node to be synchronized 102, and specifying the shard data, for instructing the node to be synchronized 102 to perform block synchronization based on the specified shard data.

[0064] The node to be synchronized 102 and the consensus node 104 may be various types of computer devices, such as terminals or servers. The terminals may be, but are not limited to, various desktop computers, laptops, smart phones, tablet computers, IoT devices and portable wearable devices. IoT devices may be smart speakers, smart TVs, smart air conditioners, smart car-mounted devices, etc. Portable wearable devices may be smart watches, smart bracelets, head-mounted devices, etc. The server may be implemented as an independent server or a server cluster consisting of multiple servers.

[0065] The blockchain block synchronization method provided in the embodiment of the present application can be applied to a data sharing system, such as Figure 2 As shown, the data sharing system 200 refers to a system for sharing data between nodes, and the data sharing system 200 may include multiple nodes 201, and the multiple nodes 201 may refer to each client in the data sharing system. In the embodiment of the present application, it may include a business response node, an identity service node, etc. Each node 201 can receive input information when performing normal work, and maintain the shared data in the data sharing system based on the received input information. In order to ensure the information intercommunication within the data sharing system, there may be an information connection between each node in the data sharing system, and information can be transmitted between nodes through the above information connection. For example, when any node in the data sharing system receives input information, other nodes in the data sharing system obtain the input information according to the consensus algorithm, and store the input information as data in the shared data, so that the data stored on all nodes in the data sharing system are consistent.

[0066] Each node in the data sharing system has a node identifier corresponding to it, and each node in the data sharing system can store the node identifiers of other nodes in the data sharing system, so that the generated blocks can be broadcast to other nodes in the data sharing system according to the node identifiers of other nodes. A node identifier list can be maintained in each node, and the node name and node identifier are stored in the node identifier list accordingly. Among them, the node identifier can be an IP (Internet Protocol, a protocol for interconnecting networks) address and any other information that can be used to identify the node. Table 1 only takes the IP address as an example for explanation.

[0067] Table 1

[0068] Node Name Node ID Node 1 117.114.151.174 Node 2 117.116.189.145 … … Node N 119.123.112.255

[0069] Each node in the data sharing system stores the same blockchain. The blockchain consists of multiple blocks, see Figure 3 The blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores the input information characteristic value, version number, timestamp and difficulty value, and the block body stores the input information; the next block of the genesis block takes the genesis block as the parent block, and the next block also includes a block header and a block body. The block header stores the input information characteristic value of the current block, the block header characteristic value, version number, timestamp and difficulty value of the parent block, and so on, so that the block data stored in each block in the blockchain is associated with the block data stored in the parent block, ensuring the security of the input information in the block.

[0070] When generating each block in the blockchain, see Figure 4 When the node where the blockchain is located receives the input information, it verifies the input information. After the verification is completed, the input information is stored in the memory pool and the hash tree used to record the input information is updated. After that, the update timestamp is updated to the time when the input information is received, and different random numbers are tried to calculate the eigenvalue multiple times so that the calculated eigenvalue can satisfy the following formula:

[0071] SHA256(SHA256(version+prev_hash+merkle_root+ntime+nbits+x))<TARGET

[0072] Among them, SHA256 is the eigenvalue algorithm used to calculate the eigenvalue; version (version number) is the version information of the relevant block protocol in the blockchain; prev_hash is the block header eigenvalue of the parent block of the current block; merkle_root is the eigenvalue of the input information; ntime is the update time of the update timestamp; nbits is the current difficulty, which is a fixed value within a period of time and is determined again after exceeding the fixed time period; x is a random number; TARGET is the eigenvalue threshold, which can be determined based on nbits. In this way, when the random number that satisfies the above formula is calculated, the information can be stored accordingly, the block header and block body can be generated, and the current block can be obtained. Subsequently, the node where the blockchain is located sends the newly generated block to other nodes in the data sharing system where it is located according to the node identification of other nodes in the data sharing system, and other nodes verify the newly generated block, and add the newly generated block to the blockchain stored in it after the verification is completed.

[0073] In one embodiment, Figure 5 As shown, a blockchain block synchronization method is provided, which is executed by a blockchain node in a blockchain network, and can be specifically executed by a node to be synchronized or other blockchain nodes other than the node to be synchronized alone, or can be executed by the node to be synchronized and other blockchain nodes other than the node to be synchronized together. In the embodiment of the present application, the method is applied to a computer device corresponding to the node to be synchronized as an example for description, and includes the following steps:

[0074] Step 502, determine the block information to be synchronized of the node to be synchronized in the blockchain network.

[0075] Among them, the blockchain network refers to a network composed of blockchain nodes, and the blockchain nodes can specifically include various types of computer devices, such as servers or terminals. The nodes to be synchronized may include blockchain nodes that need to perform block updates in the blockchain network. The blockchain nodes that need to perform block updates may be new nodes. The new nodes may include nodes newly added to the blockchain network, or nodes that currently exist in the blockchain network but whose block heights do not reach the latest block heights in the blockchain network, or nodes that currently exist in the blockchain network and come back online after being offline. The block information to be synchronized may be information describing the height information of the blocks that need to be synchronized by the nodes to be synchronized, and the block information to be synchronized may be numbers, serial numbers, etc. identified by numbers, so as to describe the height information by numbers or serial numbers, etc. Among them, the height information of the blocks that need to be synchronized may be the starting height of the blocks that need to be synchronized, and the starting height of the blocks may be the height of the blocks that the nodes to be synchronized start to update. The height information of the blocks that need to be synchronized may also be a height interval formed by the starting height of the blocks and the latest block height in the blockchain network, or a height interval formed by a certain height between the starting height of the blocks and the latest block height.

[0076] Specifically, for nodes to be synchronized that need to be synchronized in the blockchain network, such as newly added nodes in the blockchain network, they can be used as nodes to be synchronized, and the computer device can determine its own block information to be synchronized. The block information to be synchronized can be specifically represented by a number, and the number can correspond to the position of the block on the block main chain of the blockchain node. For example, when the block information to be synchronized is a height interval consisting of the block starting height and the latest block height in the blockchain network, if the node to be synchronized is a node newly added to the blockchain network, the block information to be synchronized can be 1-100, and the block number of the block is 1-100, and the number 1 represents the block at the first position on the block main chain, and the number 100 represents the block at the 100th position on the block main chain. If the node to be synchronized is a node that already exists in the blockchain network and is offline and then online again, the block information to be synchronized can be 200-500, and the block number of the block is 200-500. The number 200 represents the block at the 200th position on the block main chain, and the number 500 represents the block at the 500th position on the block main chain.

[0077] Step 504, determine each consensus node from the blockchain network based on the block information to be synchronized; the blocks included in each consensus node are matched with the block information to be synchronized.

[0078] Among them, the consensus node can be a blockchain node in the blockchain network that stores the block data of the node to be synchronized for block synchronization. The consensus node can be used to return the shard data required by the node to be synchronized, so that the node to be synchronized can complete the block synchronization according to the required shard data. The consensus node can specifically return the specified shard data according to the shard push request of the node to be synchronized, so that the node to be synchronized can complete the block synchronization. The consensus node can be determined based on the information of the block to be synchronized. When the information of the block to be synchronized is the block starting height of the block that the node to be synchronized needs to synchronize, in the blockchain network, as long as the blockchain node whose own block height reaches the block starting height can be used as a consensus node. The consensus node can also refer to the blockchain node with a higher block height in the blockchain network, that is, when the block height of the blockchain node itself reaches the set block height threshold, it can be determined as a consensus node. The super node in the blockchain network can also be determined as a consensus node. The super node can refer to a node with a relatively high equity in the blockchain network, or a node that has obtained a higher level of authority than other blockchain nodes because of a certain certification. Super nodes are usually more credible and usually have more voting rights in the blockchain network.

[0079] When specifically determining the consensus node, in addition to the block information to be synchronized of the node to be synchronized, the attribute information of the node to be synchronized itself and the attribute information of other blockchain nodes in the blockchain network other than the node to be synchronized can also be comprehensively considered, such as the resource situation, network status and synchronization requirements of the node to be synchronized, the network status and resources of the blockchain node, etc. Among them, the number of consensus nodes can be 2 or more, so that multiple consensus nodes jointly process the block synchronization request of the node to be synchronized to achieve block synchronization of the node to be synchronized.

[0080] Among them, the blocks included in each consensus node are matched with the block information to be synchronized respectively, which means that the blocks included in each consensus node need to match the block information to be synchronized. When the block information to be synchronized is the block starting height, the block height of each consensus node needs to cover the block starting height that currently needs to be updated, that is, in each consensus node, the block height of all consensus nodes needs to reach the block starting height that needs to be updated by the node to be synchronized.

[0081] Specifically, the computer device can determine each consensus node from the blockchain network based on the determined block information to be synchronized. When determining the consensus node, the computer device can select from the blockchain network only based on the block information to be synchronized. For example, when the block information to be synchronized is the block start height, the node whose block height reaches the block start height in the blockchain node can be determined as the consensus node. When the block information to be synchronized is a height interval composed of a certain height between the block start height and the latest block height, as long as the block height of each blockchain node can cover the height interval to be updated, it can be determined as a consensus node.

[0082] For example, for the case where the block information to be synchronized is numbered 1-1000, the computer device can determine any blockchain node in the blockchain network with a block height greater than or equal to 1000 as a consensus node; for the height interval numbered 200-500, the computer device can determine any blockchain node in the blockchain network with a block height greater than or equal to 500 as a consensus node. The computer device can also combine the block information to be synchronized with the physical distance between the blockchain node and the node to be synchronized, the network status of each blockchain node, the IP address, etc., to comprehensively determine the consensus node. In the specific implementation, for the blocks with block information to be synchronized numbered 50-100, the computer device determines that each consensus node needs to cover the 100th block before the block synchronization can be completed. As for the number of consensus nodes, it can be 2, 10, or 100. No matter how many consensus nodes there are, as long as the height covered by each consensus node reaches the 100th block.

[0083] Step 506, based on the block information to be synchronized, the number of consensus nodes, and the block shard index information of each consensus node, generate a shard push request configured for each consensus node.

[0084] Among them, the number of nodes of the consensus node can be the number of determined consensus nodes. The block sharding index information can be the index information used to determine the sharding data pushed by each consensus node. According to the block sharding index information, the sharding data that the consensus node needs to feedback can be determined, that is, the block sharding index information can be used to instruct different consensus nodes to return different data, so as to perform concurrent block synchronization processing for the nodes to be synchronized. The block sharding index information can specifically be any symbol that can be used for identification, such as numbers, letters, and feature codes, as long as different consensus nodes can be distinguished. The sharding push request can be a request sent to the consensus node to indicate the sharding data required for the consensus node to feedback. According to the block information to be synchronized, the number of nodes of the consensus node, and the block sharding index information of each consensus node, the sharding push request assigned to each consensus node can be obtained.

[0085] Specifically, the computer device can determine the number of nodes of the consensus node, specifically, the number of consensus nodes can be counted to obtain the number of nodes, or the preset number of nodes can be queried. For each consensus node, it is responsible for feeding back different data to the node to be synchronized for synchronization, and the block shard index information is used to identify the data fed back by each consensus node. The computer device can determine the block shard index information of each consensus node, and based on the block information to be synchronized, the number of nodes of the consensus node, and the block shard index information of each of the consensus nodes, obtain the shard push request configured for each consensus node. For each consensus node, a matching shard push request will be sent. In a specific application, the block shard index information may be determined based on the node ID (Identity document) of each consensus node. If the computer device determines a total of three consensus nodes, consensus node 1, consensus node 2, and consensus node 3, 1, 2, and 3 may refer to the node IDs of the consensus nodes. The computer device may first sort the consensus nodes according to the node IDs of the consensus nodes, such as sorting them according to the numerical values ​​of the node IDs, and then assign corresponding shard indexes to each consensus node according to the sorting. For consensus node 1, the computer device may determine that its corresponding block shard index information is shard index 1, and consensus node 1 needs to synchronize the first shard data. For consensus node 2, the computer device may determine that its corresponding block shard index information is shard index 2, and consensus node 2 needs to synchronize the second shard data. For consensus node 3, the computer device may determine that its corresponding block shard index information is shard index 3, and consensus node 3 needs to synchronize the third shard data.

[0086] Step 508, sending a shard push request for each configuration to each consensus node; the shard push request is used to instruct the receiving consensus node to return the specified shard data in the block to be synchronized determined based on the block information to be synchronized; the specified shard data is the shard data in each shard data that matches the block shard index information in the received shard push request; each shard data is obtained by the receiving consensus node dividing the block to be synchronized into shards according to the number of nodes.

[0087] Among them, the designated shard data may refer to the shard data returned by the consensus node that matches its own block index information. The shard data is the data obtained by the consensus node by sharding the block to be synchronized according to the number of nodes in the received shard push request. The shard data may specifically be the segmented data obtained by dividing the block to be synchronized as a whole. The block to be synchronized is a block that needs to be synchronized for the node to be synchronized according to the information of the block to be synchronized, and may specifically include one or more blocks. For example, the block to be synchronized may be block A, and the number of nodes is 3, then block A may be divided into three equal parts to obtain shard data 1, shard data 2, and shard data 3. For another example, the block to be synchronized may be blocks 1-10, and the number of nodes is 4, then blocks 1-10 may be divided into four equal parts to obtain shard data 1, shard data 2, shard data 3, and shard data 4. The designated shard data is the shard data that matches the block shard index information among the shard data obtained by dividing the block to be synchronized. For example, if the block shard index information in the shard push request received by consensus node X is block shard index 1, then consensus node X returns the shard data of block shard index 1 in each shard data as the designated shard data to the node to be synchronized; for another example, if the block shard index information in the shard push request received by consensus node Y is block shard index 3, then consensus node Y returns the shard data of block shard index 3 in each shard data as the designated shard data to the node to be synchronized.

[0088] Specifically, the computer device sends the configured shard push request to each consensus node to instruct the consensus node to return the specified shard data. Different consensus nodes correspond to different block shard index information, and each consensus node can return the specified shard data that matches the block index information. After receiving the shard push request, the consensus node can determine the block information to be synchronized from the received shard push request, and can determine the block to be synchronized based on the block information to be synchronized. The number of blocks to be synchronized can be one or more. The consensus node divides the block to be synchronized into shards according to the number of nodes carried in the shard push request, obtains each shard data, and determines the shard data that matches the block shard index information in the shard push request from each shard data, and uses the shard data as the specified shard data. For example, the determined consensus nodes include 2, namely consensus node 1 and consensus node 2, and consensus node 1 and consensus node 2 correspond to block shard index information respectively. Consensus node 1 corresponds to block shard index 1, and consensus node 2 corresponds to block shard index 2. For the shard push requests sent to different consensus nodes, the block information to be synchronized and the number of consensus nodes sent by the computer device to each consensus node may be the same, but the block shard index information is different. When the block information to be synchronized is the height interval 200-300, the information included in the shard push request of consensus node 1 may include the height interval 200-300 to be synchronized, the number of consensus nodes 2, and the block shard index 1, and the information included in the shard push request of consensus node 2 may include the height interval 200-300 to be synchronized, the number of consensus nodes 2, and the block shard index 2.

[0089] Step 510: perform block synchronization on the nodes to be synchronized according to the designated shard data returned by each consensus node.

[0090] Specifically, each consensus node can return the corresponding designated shard data. After receiving the designated shard data returned by each consensus node, the node to be synchronized can verify the designated shard data, such as whether the transaction involved in the designated shard data is legal, whether the designated shard data is complete, etc. After the designated shard data is verified to be qualified, the node to be synchronized can process the designated shard data in sequence according to the set block placement order to perform block synchronization. For example, the number of nodes is 3, and the corresponding consensus nodes are consensus node K, consensus node M, and consensus node N, and the block shard index information of each consensus node is block shard index 1, block shard index 2, and block shard index 3. For the block to be synchronized, consensus node K, consensus node M, and consensus node N will return the specified shard data of block shard index 1, the specified shard data of block shard index 2, and the specified shard data of block shard index 3 respectively after dividing the block to be synchronized into three equal parts. The node to be synchronized can obtain the complete block data to be synchronized according to the obtained specified shard data, so as to perform block synchronization.

[0091] In a specific application, such as Figure 6 As shown, the new node completes its own block synchronization through the new node. Among them, the new node can be a node newly added to the blockchain network. In the blockchain network, in addition to the new node, it also includes multiple blockchain nodes, such as blockchain node 1, blockchain node 1...blockchain node N. The new node can determine its own block information. In the case where the new node is a node newly added to the blockchain network, if the block information to be synchronized is the block starting height, the block information to be synchronized is 1, indicating that the new node needs to synchronize the block with a height of 1. If the information to be synchronized is a height interval composed of a certain height between the block starting height and the latest block height, the block information to be synchronized can be 1-100, indicating that the new node needs to synchronize blocks with a height of 1-100.

[0092] Among them, the blockchain nodes in the blockchain network can automatically send their own node information to the new node when determining that there is a new node in the blockchain network. Of course, the new node can also first send a node information acquisition request to each blockchain node in the blockchain network. After receiving it, each blockchain node will then feedback its own node information to the new node based on the node information acquisition request. Among them, the node information can only include the block height of each blockchain node, or it can include the IP address, network stability parameters, and computing resources of the blockchain node. Blockchain node 1 can feedback node information 1 to the new node, blockchain node 2 can feedback node information 2 to the new node, and blockchain node N can feedback node information 3 to the new node.

[0093] Based on the received node information 1, node information 2, and node information 3, the new node can determine the consensus node from blockchain node 1, blockchain node 2, and blockchain node N in combination with its own block information to be synchronized. When each node information only includes the own block height of each blockchain node, the new node can determine the blockchain node that meets the height requirement as the consensus node. When each node information includes not only the own block height of each blockchain node, but also the network stability parameters and computing resources of each blockchain node, the new node can determine the blockchain node that meets the height requirement, network stability requirement, and computing resource requirement as the consensus node. For example, in the case where each node information only includes the own block height of each blockchain node, if the block height of blockchain node 1 itself is 6, the block height of blockchain node 2 itself is 7, and the block height of blockchain node N itself is 5, when the block information to be synchronized is 1-6, blockchain node 1 and blockchain node 2 can be used as consensus nodes.

[0094] Based on the determined consensus node, the new node can obtain the shard push request configured for blockchain node 1 and blockchain node 2 respectively. The shard push request can mainly include the block information to be synchronized, the number of consensus nodes, and the block shard index information of each consensus node. Among them, the block shard index information can indicate which shard data each consensus node returns. The block shard index information can be determined based on the node ID of each consensus node. The 1 of blockchain node 1 and the 2 of blockchain node 2 can be the node ID. The new node can sort blockchain node 1 and blockchain node 2 according to the node ID, determine the shard index 1 corresponding to blockchain node 1, and determine the shard index 2 corresponding to blockchain node 2.

[0095] Based on the received shard push request, blockchain node 1 and blockchain node 2 perform data byte sharding on the blocks corresponding to the block information to be synchronized 1-6 according to the number of consensus nodes, and two shard data can be obtained. Blockchain node 1 can determine the first shard data corresponding to shard index 1 from the two shard data based on shard index 1 and return it to the new node. Blockchain node 2 can determine the two shard data corresponding to shard index 2 from the shard data and return them to the new node based on shard index 2, so that the blockchain node can determine the shard data to be returned according to the set block shard index information, which is conducive to reducing the number of times block synchronization requests are sent. After completing the synchronization of a block to be synchronized, blockchain node 1 and blockchain node 2 can continue to determine the designated shard data for the next block to be synchronized according to the pre-set block shard index information, so that the designated shard data can be continuously returned without repeatedly sending shard push requests, thereby improving the efficiency of block synchronization.

[0096] The new node can perform verification based on the received first shard data and the second shard data, such as verifying whether the transactions involved in the first shard data and the second shard data are legal and complete. After the first shard data and the second shard data are verified to be qualified, the node to be synchronized can synchronize the first shard data and the second shard data in turn according to the set block landing order, thereby realizing concurrent synchronization processing.

[0097] In the above blockchain block synchronization method, the block information to be synchronized of the node to be synchronized in the blockchain network is determined, and based on the block information to be synchronized, the consensus nodes whose blocks are included are determined from the blockchain network and match the block information to be synchronized respectively. According to the block information to be synchronized, the number of consensus nodes and the block shard index information of each consensus node, a shard push request configured for each consensus node is generated. After the shard push request is sent to each consensus node, it is used to instruct each consensus node to return the specified shard data in the block to be synchronized determined based on the block information to be synchronized. The specified shard data is the shard data in each shard data that matches the block shard index information in the received shard push request. The receiving consensus node divides the included block to be synchronized into shards according to the number of nodes to obtain the shard data. According to the specified shard data returned by each consensus node, block synchronization is performed for the node to be synchronized. During the blockchain block synchronization process, each consensus node is determined based on the to-be-synchronized block information of the to-be-synchronized node, and a shard push request configured for each consensus node is generated according to the to-be-synchronized block information, the number of consensus nodes, and the block shard index information of each consensus node. After the shard push request is sent to each consensus node, it is used to instruct the receiving consensus node to return the specified shard data based on the shard push request, so that block synchronization can be performed according to the specified shard data returned by each consensus node, and multiple consensus nodes can be effectively scheduled for block synchronization, thereby improving the synchronization efficiency of blocks in the blockchain.

[0098] In one embodiment, each consensus node is determined from the blockchain network based on the block information to be synchronized, including: obtaining node status information of each blockchain node in the blockchain network; based on the block information to be synchronized and the node status information of each blockchain node, screening each consensus node from each blockchain node.

[0099] Among them, the node status information may be information used to characterize the status of a blockchain node, and the status of a blockchain node may include information such as the block height, network status, and computing resources of the blockchain node. Specifically, the computer device may screen each blockchain node based on the block information to be synchronized, such as the block information to be synchronized being the starting height of the block to be synchronized, and the node status information of each blockchain node, such as the node status information including the block height, computing resources, and network status parameters of the blockchain node, and the computer device may screen each blockchain node based on its own starting height of the block to be synchronized, and the block height, computing resource network status parameters, and the like of each blockchain node, and obtain a consensus node from each blockchain node.

[0100] In a specific application, the computer device can combine the starting height of the block to be synchronized, the node block height of each blockchain node and the network stability parameter to select each consensus node from each blockchain node, wherein the node block height of the consensus node is not less than the starting height of the block to be synchronized, and the network stability parameter of the consensus node meets the stability parameter screening condition. Among them, when the computer device determines each consensus node in combination with the starting height of the block to be synchronized, the node block height of each blockchain node and the network stability parameter, it can first compare the starting height of the block to be synchronized and the node block height of each blockchain node in terms of height, and then determine the consensus node in combination with the network stability parameter of each blockchain node. The computer can also first make a preliminary screening based on the network stability parameter, and then make a height comparison based on the starting height of the block to be synchronized and the node block height of each blockchain node to determine the consensus node. Whether to compare the height first or make a preliminary screening based on the network stability parameter first can be considered comprehensively in combination with the actual operation of the blockchain network, the efficiency requirements of block synchronization, etc.

[0101] In this embodiment, the computer device selects better consensus nodes from the blockchain nodes based on the block information to be synchronized and the node status information of each blockchain node, thereby improving the stability and reliability of block synchronization, and helping to reduce the number of times that block synchronization requests need to be resent due to consensus nodes, thereby improving the synchronization efficiency of blocks in the blockchain.

[0102] In one embodiment, the block information to be synchronized includes the starting height of the block to be synchronized for the node to be synchronized; the node status information includes the node block height and network stability parameters of the blockchain node to which it belongs. Figure 7 As shown, the process of determining the consensus node, that is, screening each consensus node from each blockchain node based on the block information to be synchronized and the node status information of each blockchain node, includes the following steps:

[0103] Step 702, according to the node block height of each blockchain node, select candidate nodes from each blockchain node; the node block height of the candidate node is not less than the starting height of the block to be synchronized.

[0104] Among them, the starting height of the block to be synchronized can be used to characterize the block height corresponding to the block that the node to be synchronized starts to update. The starting height of the block to be synchronized can be specifically the height of the next block of the current block of the node to be synchronized; the starting height of the block to be synchronized can also be a starting height set according to the current block height, actual state, type and attributes of the node to be synchronized. For example, for a certain node to be synchronized 1, the starting height of the block to be synchronized corresponding to it is set to 100, and for a node to be synchronized 2, the starting height of the block to be synchronized corresponding to it is set to 200. Candidate nodes can refer to blockchain nodes that meet the height conditions in the blockchain network. Candidate nodes can be obtained by screening blockchain nodes based on the starting height of the block of the node to be synchronized and the node block height of each blockchain node. Specifically, blockchain nodes whose node block height in the blockchain node is equal to the starting height of the block to be synchronized or whose node block height is greater than the starting height of the block to be synchronized are screened as candidate nodes.

[0105] Specifically, the computer compares the node starting height of the node to be synchronized and the block height of each blockchain node to obtain a height comparison result, and screens the blockchain nodes according to the height comparison result, and screens the candidate nodes whose node block height is not less than the starting height of the block to be synchronized from the blockchain nodes. In a specific application, the starting height of the block to be synchronized can be the height of the next block of the current block of the node to be synchronized. For different nodes to be synchronized, the starting height of the block to be synchronized of the node to be synchronized can also be different. If the node to be synchronized is a node newly connected to the blockchain network, and the current height of the node to be synchronized is 0, the starting height of the block to be synchronized can be 1; if the node to be synchronized is a blockchain node that already exists in the blockchain network and is offline and then online again, then when the current block height of the node to be synchronized is 20, the starting height of the block to be synchronized can be 21.

[0106] Step 704, according to the network stability parameters of the candidate nodes, determine from the candidate nodes the consensus nodes whose network stability parameters meet the stability parameter screening conditions.

[0107] Among them, the network stability parameter can be a parameter used to characterize the network stability of the candidate node. The larger the value of the network stability parameter is, the better the network stability can be. The stability parameter screening condition can be a condition set for screening the reference node. By screening the reference node, the consensus node can be determined. When setting the stability parameter screening condition, the network stability parameter threshold can be set in combination with the number of candidate nodes, the network conditions of the candidate nodes, etc., and the stability parameter screening condition is determined according to the stability parameter threshold. For example, if the stability parameter threshold is determined according to the number of candidate nodes, a larger stability parameter threshold can be set when the number of candidate nodes is large, so that a reference node with a more stable network can be selected as much as possible while ensuring the number of determined consensus nodes, thereby improving the stability of block synchronization. For example, when selecting a reference node according to the network status of each candidate node, the overall network status of the reference node can be analyzed first. When the overall network status is good, a larger stability parameter threshold can be set, and when the overall network status is poor, a smaller stability parameter threshold can be set. Of course, when actually determining the stability parameter screening condition, it can be set according to the requirements for block synchronization accuracy and efficiency requirements of block synchronization.

[0108] Specifically, the computer device can determine the network stability parameters of each candidate node, and the stability parameter screening condition can be that the network stability parameter is not less than the stability parameter threshold. When the computer device determines that the network stability parameter of the candidate node is greater than or equal to the stability parameter threshold, it is determined that the stability parameter screening condition is met, and the candidate node can be determined as a consensus node. When the computer device determines that the network stability parameter of the candidate node is less than the stability parameter threshold, it is determined that the stability parameter screening condition is not met, and the candidate node may not be temporarily determined as a consensus node. In specific implementation, the computer device can set the stability parameter threshold in combination with the overall network status of the reference node. When it is determined that the network status of the reference node is good, the computer device can set the stability parameter threshold to 85%. If there is a reference node with a network stability parameter of 89%, the reference node can be determined as a consensus node. If there is a reference node with a network stability parameter of 80%, the reference node is temporarily not determined as a consensus node.

[0109] In one embodiment, when the computer device selects each consensus node from each blockchain node according to the starting height of the block to be synchronized, the node block height of each blockchain node and the network stability parameter, it can first perform the screening based on the network stability parameter, that is, first determine the nodes in the blockchain node that meet the stability parameter screening conditions as reference nodes, and then perform height screening on each reference node according to the starting height of the block to be synchronized and the node block height of each blockchain node, and determine the node whose node block height is not less than the starting height of the block to be synchronized from each reference node as the consensus node. It should be noted that when first screening according to the network stability parameter and then screening based on the height, the network stability parameter screening should be performed to filter out nodes that are obviously not suitable for synchronization, that is, the stability parameter threshold can be adaptively set to be smaller, so that the network stability screening conditions are more relaxed, so as to ensure that there are enough nodes that meet the height requirements.

[0110] In this embodiment, the computer device screens each blockchain node based on the starting height of the block to be synchronized, the node block height of each blockchain node, and the network stability parameters, and can accurately select better nodes from the blockchain nodes as consensus nodes, thereby improving the efficiency of block synchronization.

[0111] In one embodiment, based on the network stability parameters of each candidate node, each consensus node whose network stability parameters meet the stability parameter screening condition is determined from the candidate nodes, including: obtaining a stable node list constructed based on the network stability parameters of each candidate node; the stable node list includes candidate nodes whose network stability parameters are not less than the stability parameter threshold; and determining each consensus node from the stable node list.

[0112] The stable node list may be a list of candidate nodes set to maintain a network stability parameter not less than a stability parameter threshold. When the computer device determines that the network stability parameter of the candidate node is greater than the stability parameter threshold, or the network stability parameter is equal to the stability parameter threshold, the candidate node may be stored in the stable node list.

[0113] Specifically, the computer device can directly select each consensus node from the candidate nodes in the stable node list. Generally, the number of consensus nodes is not less than two. When determining the consensus node only based on the stable node list, the number of candidate nodes in the stable node list can be assumed to be greater than or equal to two. The computer device can directly determine all candidate nodes in the stable node list as consensus nodes. The computer device can also determine the number of consensus nodes required in combination with the block height that the node to be synchronized needs to synchronize, or directly pre-set the number of consensus nodes required, so that the computer device can select candidate nodes from the stable node list as consensus nodes according to the number of consensus nodes required.

[0114] In a specific implementation, when the computer device determines the consensus node from the stable node list according to the required number of consensus nodes, if the number of candidate nodes in the stable node list meets the required number of consensus nodes, that is, the number of candidate nodes in the stable node list is greater than or equal to the required number of consensus nodes, then the computer device can directly determine the corresponding number of candidate nodes in the stable node list as consensus nodes according to the required number of consensus nodes. If the number of candidate nodes in the stable node list is 20 and the required number of consensus nodes is 10, then 10 candidate nodes can be directly selected from the stable node list as consensus nodes. If the number of candidate nodes in the stable node list does not meet the required number of consensus nodes, that is, the number of candidate nodes in the stable node list is less than the required number of consensus nodes, then the computer device can consider adjusting the required number of consensus nodes, so that the consensus node can be determined only from the stable node list. On the one hand, the computer device can multiply the required number of consensus nodes by a certain preset ratio to obtain the new required number of consensus nodes, and then determine the consensus node from the stable node list according to the new required number of consensus nodes. For example, if the number of candidate nodes in the stable node list is 10 and the number of consensus nodes required is 20, when the preset ratio is 20%, 20 can be multiplied by 20% to obtain a new number of consensus nodes required of 4. On the other hand, the computer device can also directly determine all candidate nodes in the stable node list as consensus nodes. For example, if the number of consensus nodes required is 10, but there are only 9 candidate nodes in the stable list, which is only 1 short, the computer device can consider only these 9 as consensus nodes.

[0115] In a specific application, when the number of candidate nodes in the stable node list is greater than or equal to the number of required consensus nodes, the computer device can prioritize the network stability parameters as consensus nodes based on the numerical values ​​of the network stability parameters of each candidate node in the stable node list. The computer device can also prioritize the candidate nodes with the closest physical distance and IP address as consensus nodes based on the physical distance and IP address (Internet Protocol Address) between each candidate node and the node to be synchronized. The computer device can also prioritize the candidate nodes with stronger computing resources as consensus nodes based on the computing resources of the candidate nodes. When determining the consensus node based on the candidate nodes, the computer device can determine it based on the efficiency requirements and accuracy requirements of block synchronization.

[0116] In this embodiment, the computer device selects each consensus node from the candidate nodes in the stable node list, so that the network stability of the consensus node is better. By selecting the consensus node with better network stability for block synchronization, the synchronization efficiency of the blocks in the blockchain is improved.

[0117] In one embodiment, the blockchain block synchronization method also includes: when the number of stable nodes of the candidate nodes included in the stable node list is less than the required number of synchronization nodes for the node to be synchronized, obtaining a supplementary node list; the supplementary node list includes candidate nodes whose network stability parameters are less than the stability parameter threshold; obtaining supplementary nodes from the supplementary node list according to the number of supplementary nodes; the number of supplementary nodes is determined based on the difference between the required number of synchronization nodes and the number of stable nodes; and obtaining each consensus node based on the candidate nodes included in the supplementary node list and the stable node list.

[0118] The number of stable nodes may be the number of candidate nodes in the stable node list, and the number of synchronization nodes required may be the number of consensus nodes required. When the number of candidate nodes in the stable node list is less than the number of consensus nodes required for the node to be synchronized, in addition to adjusting the number of required consensus nodes, supplementary nodes may be selected from the supplementary node list so that the number of determined consensus nodes meets the number of synchronization nodes required for the node to be synchronized. The supplementary node list may be a list of candidate nodes for maintaining a network stability parameter less than a stability parameter threshold, and the number of supplementary nodes may be the difference between the number of synchronization nodes required and the number of stable nodes.

[0119] Specifically, when the number of candidate nodes in the stable node list does not meet the number of consensus nodes required for the node to be synchronized, the computer device can determine the node number difference between the number of candidate nodes in the stable node list and the number of consensus nodes required, select a supplementary node that matches the node number difference from the supplementary node list according to the node number difference, and obtain each consensus node according to the supplementary node and the candidate nodes included in the stable node list. In a specific implementation, when the computer device selects a supplementary node from the supplementary node list, it can prioritize the network stability parameter as the supplementary node according to the numerical value of the network stability parameter of each candidate node in the supplementary node list. For example, in the supplementary node list, there are candidate nodes 1 with a network stability parameter of 78%, candidate nodes 2 with a network stability parameter of 65%, and candidate nodes 3 with a network stability parameter of 76%. When two candidate nodes need to be selected as supplementary nodes, the computer device can select candidate nodes 1 and candidate nodes 3 as supplementary nodes, so that the determined consensus nodes can be relatively network stable as much as possible.

[0120] In this embodiment, when the number of candidate nodes in the stable node list of the computer device does not meet the number of consensus nodes required for the node to be synchronized, a supplementary node can be selected from the supplementary node list, and a consensus node can be determined based on the supplementary node and the candidate nodes in the stable node list, so that the number of consensus nodes can meet the required number of synchronization nodes for the node to be synchronized, thereby ensuring the efficiency of block synchronization while carrying out block synchronization based on as many consensus nodes as possible.

[0121] In one embodiment, the blockchain block synchronization method also includes: obtaining a stability parameter threshold and a network stability parameter of each candidate node; adding the candidate nodes whose network stability parameters are not less than the stability parameter threshold to a first node list to obtain a stable node list; adding the candidate nodes whose network stability parameters are less than the stability parameter threshold to a second node list to obtain a supplementary node list.

[0122] Specifically, the first node list and the second node list are lists storing candidate nodes. If the network stability parameter of the candidate node is greater than or equal to the stability parameter threshold, the candidate node can be added to the first node list to obtain a stable node list. If the network stability parameter of the candidate node is less than the stability parameter threshold, the candidate node can be added to the second node list to obtain a supplementary node list. The stable node list and the supplementary node list can be relative concepts. The candidate nodes in the stable node list are nodes with more stable network stability than the candidate nodes in the supplementary node list under a set stability parameter threshold. The network state of the candidate nodes stored in the stable node list is not necessarily absolutely stable, while the network state of the candidate nodes stored in the supplementary node list is not necessarily absolutely unstable. The candidate nodes in the stable node list and the supplementary node list can depend on the selection of the stability parameter threshold. If the network stability parameter of the candidate node is 60%, if the stability parameter threshold is set to 70%, the computer device can add the candidate node to the supplementary node list, and if the stability parameter threshold is set to 50%, the computer device can add the candidate node to the stable node list.

[0123] In this embodiment, the computer device can determine a stable node list and a supplementary node list by setting a first node list and a second node list, combining the stability parameter threshold and the network stability parameters of each candidate node, so that the consensus node can be determined in combination with the stable node list and the supplementary node list, thereby improving the efficiency of determining the consensus node.

[0124] In one embodiment, the network stability parameter is obtained through a stability parameter determination step; the stability parameter determination step includes: receiving a node heartbeat message sent by each blockchain node; performing statistics based on the node heartbeat messages sent by each blockchain node to obtain the heartbeat statistical parameters of each blockchain node; and determining the network stability parameter of the associated blockchain node based on the heartbeat statistical parameters.

[0125] Among them, the network stability parameter can be calculated in real time when the consensus node is selected, or it can be calculated in advance before the consensus node is selected. The node heartbeat message can be a message sent by the blockchain node to the node to be synchronized. The computer device can determine the connectivity status, whether a fault occurs, and whether it is offline, etc. of each blockchain node according to the node heartbeat message of the blockchain node. If a node heartbeat message sent by a blockchain node is received, it can be considered that the blockchain node is connected. The heartbeat statistical parameter can be a parameter obtained after statistical analysis of the node heartbeat message. The heartbeat statistical parameter can specifically be a statistical parameter obtained after statistics of the node heartbeat messages sent by each blockchain node within a preset time period, which can be used to characterize the offline status, connectivity status, etc. of each blockchain node within the preset time period. The preset time period can include at least one heartbeat cycle, and the heartbeat cycle can be the time for each statistical node heartbeat message reception situation within the preset time period. Within a preset time period, if the preset time period is 60 minutes, it can include 6 heartbeat cycles, and the time of each heartbeat cycle is 10 minutes. The node heartbeat message can be counted once every 10 minutes.

[0126] Specifically, the computer device can obtain the node heartbeat message of each blockchain node within a preset time period. There are multiple heartbeat cycles within the preset time period. The computer device can count the node heartbeat messages of the blockchain node within multiple heartbeat cycles, such as including heartbeat cycle 1, heartbeat cycle 2 and heartbeat cycle 3. The computer device can respectively analyze the situation of receiving the node heartbeat message within heartbeat cycle 1, heartbeat cycle 2 and heartbeat cycle 3 to obtain the analysis result. The computer device can further count the analysis results of the heartbeat cycle 1, heartbeat cycle 2 and heartbeat cycle 3 respectively, and determine the heartbeat statistical parameters corresponding to each blockchain node. Combined with the heartbeat statistical parameters, the network stability parameters are calculated. When determining the network stability parameters according to the heartbeat statistical parameters, the computer device can use a pre-set network stability parameter calculation formula, or it can be determined by any other means.

[0127] In this embodiment, the computer device can count the node heartbeat messages sent by each blockchain node, determine the heartbeat statistical parameters of each blockchain node, and then determine the network stability parameters of the blockchain node based on the heartbeat statistical parameters. Since the node heartbeat message of the blockchain node is related to the connectivity status of the blockchain node, the network status of the blockchain node can be accurately determined, thereby improving the stability of the block synchronization process and improving the efficiency of block synchronization to a certain extent.

[0128] In one embodiment, the heartbeat statistical parameters include the number of consecutive heartbeats and the number of offline times; the number of consecutive heartbeats indicates the number of consecutively received node heartbeat messages; the number of offline times indicates the number of times the node connection is interrupted; the network stability parameters of the associated blockchain node are determined based on the heartbeat statistical parameters, including: when the number of consecutive heartbeats exceeds a consecutive number threshold, the network stability parameters of the associated blockchain node are determined according to the number of consecutive heartbeats and the number of offline times.

[0129] Among them, the number of consecutive heartbeats may refer to the number of node heartbeat messages received continuously. In the case of multiple heartbeat cycles, if a node heartbeat message is received in each heartbeat cycle, it means that the node heartbeat message is received continuously. Of course, it can also be set that if a node heartbeat message is received within a preset heartbeat cycle, it means that the node heartbeat message is received continuously, wherein the preset heartbeat cycle can be two or any other number. The number of offline times may indicate the number of times the node connection is interrupted, and the node connection interruption may be that the node heartbeat message of the blockchain node is not received within one heartbeat cycle, or that the node heartbeat message of the blockchain node is not received within multiple heartbeat cycles, such as that the node heartbeat message of the blockchain node is not received within two consecutive heartbeat cycles. The continuous number threshold may be a threshold set for determining whether to calculate the network stability parameter. When setting the continuous number threshold, it may be set in combination with the network status, computing resources, etc. of each blockchain node in the blockchain network.

[0130] Specifically, the computer device can determine the number of consecutive heartbeats and offline times of each blockchain node. When the number of consecutive heartbeats reaches the consecutive number threshold, the consecutive number threshold can be set to 50, that is, when the number of consecutive heartbeats reaches 50, the computer device can calculate the corresponding network stability parameter according to the number of consecutive heartbeats and offline times of each blockchain node. When the computer device calculates the corresponding network stability parameter according to the number of consecutive heartbeats and offline times, it can determine the number of consecutive heartbeats and offline times based on the sum of the number of consecutive heartbeats and offline times, and then determine the quotient of the number of consecutive heartbeats and the number of times as the network stability parameter.

[0131] In this embodiment, the computer device can accurately calculate the network stability parameters of the blockchain node through the number of consecutive heartbeats and the number of offline times. Since the network stability parameters can affect the selection of consensus nodes, the accuracy of consensus node selection can be improved, and the block synchronization efficiency can be improved to a certain extent.

[0132] In one embodiment, before receiving the node heartbeat message sent by each blockchain node, the method also includes: continuously sending broadcast messages in the blockchain network through the node to be synchronized; the broadcast message is used to instruct each blockchain node in the blockchain network to feed back the node heartbeat message respectively.

[0133] Among them, the broadcast message refers to a message used to instruct the blockchain node to feedback the node heartbeat message. When sending the broadcast message, it can be continuously sent according to the preset time condition. The preset time condition can be a set sending time interval or a set sending time point. Specifically, the computer device can follow the preset time condition. When the preset time condition is a set sending time point, such as the sending time point is 7 o'clock, 8 o'clock, 9 o'clock and 10 o'clock every day, then when it reaches 7 o'clock, 8 o'clock, 9 o'clock and 10 o'clock, the computer device will send a broadcast message in the blockchain network. Among them, the block height of the node to be synchronized can be carried in the broadcast message, so that the blockchain node whose height reaches the block height of the node to be synchronized can be instructed to feedback the node heartbeat message.

[0134] Furthermore, based on the node heartbeat messages sent by each blockchain node, statistics are respectively performed to obtain the heartbeat statistical parameters of each blockchain node, including: counting the number of continuous receptions of the blockchain nodes associated with the received node heartbeat messages, to obtain the number of continuous heartbeats of each blockchain node; counting the number of non-receptions of the blockchain nodes associated with the non-received node heartbeat messages, to obtain the number of offline times of each blockchain node.

[0135] Specifically, the continuous reception number may refer to that for any blockchain node, the node heartbeat message of the blockchain node can be received in the continuous heartbeat cycle within the preset time period without interruption. The number of unreceived messages may be the number of times the node heartbeat message is received within the preset time period. The computer device may set the initial values ​​of the continuous heartbeat number and the offline number of each blockchain node for each blockchain node, such as the initial values ​​of the continuous heartbeat number and the offline number may be 0, and update the continuous heartbeat number according to the continuous reception number, and update the offline number according to the unreceived number. If there are 10 heartbeat cycles in the preset time period, if the node heartbeat message of the blockchain node 1 is received within the 3rd to 7th consecutive heartbeat cycles, the continuous reception number of the blockchain node 1 is 5, and the continuous heartbeat number of the blockchain node 1 is obtained according to the continuous reception number; if the node heartbeat message of the blockchain node 2 is not received in the 1st, 2nd and 8th heartbeat cycles in 10 heartbeat cycles, it can be determined that the number of unreceived messages is 3, and the number of offline times of the blockchain node 2 is obtained according to the number of unreceived messages.

[0136] In specific implementation, the computer device can directly determine the number of continuous receptions as the number of continuous heartbeats associated with the blockchain node. The computer device can directly determine the number of non-receptions as the number of offline times associated with the blockchain node, or determine the number of offline times based on the relationship between the heartbeat cycles in which the non-reception number is located. The computer device can count the number of offline times of the blockchain node once when the node heartbeat message of the blockchain node is not received within a preset number of consecutive heartbeat cycles. The number of consecutive preset heartbeat cycles can be determined based on the number of blockchain nodes in the blockchain network, the network status of the blockchain node, etc. For example, for blockchain node 2, in 8 heartbeat cycles, the node heartbeat message of blockchain node 2 is not received in the 1st, 2nd and 8th heartbeat cycles. If it is determined that the node heartbeat message of the blockchain node is not received within 2 consecutive heartbeat cycles, the number of offline times of the blockchain node is counted once, and the number of offline times of blockchain node 2 is 1.

[0137] In this embodiment, the computer device obtains the number of consecutive heartbeats by counting the number of consecutive receptions, and obtains the number of offline times according to the number of unreceived data, so as to accurately calculate the network stability parameters of the blockchain node. Since the network stability parameters can affect the selection of consensus nodes, the accuracy of consensus node selection can be improved. While ensuring the accuracy of consensus node selection, it is possible to avoid selecting consensus nodes with unstable networks, thereby improving the efficiency of block synchronization.

[0138] In one embodiment, each consensus node is determined from the blockchain network based on the block information to be synchronized, including: determining the target block information according to the block information to be synchronized and the unit synchronization block information for the node to be synchronized; sharding the target block information into data bytes according to the number of shard synchronization nodes to be synchronized for the node to be synchronized, to obtain each block information shard; determining each consensus node from the blockchain network based on each block information shard; and matching the blocks included in each consensus node with the block information shard respectively.

[0139] Among them, the unit synchronization block information can be information used to describe the height interval of the blocks that need to be updated each time by the synchronization node, and specifically can be the number of blocks that need to be updated each time. The target block information can be the block information that needs to be updated once determined based on the block information to be synchronized and the target block information, that is, how many blocks need to be updated each time, the height of the blocks that need to be updated, the block height interval of the blocks that need to be updated, etc. If the height interval determined by the unit synchronization block information is that the synchronization node only updates one block each time, the target block information can be determined by the starting height of the block. If the synchronization node updates multiple blocks each time, the unit synchronization block information can be the height interval of the blocks to be updated, and the height interval of the blocks to be updated can be represented by a number or a sequence number.

[0140] When the block information to be synchronized is the starting height of the block, if the height interval of the block to be updated is 1 according to the unit synchronization block information, it means that only one block is updated at a time, and the determined target block information can be the starting height of the block. When the block information to be synchronized is the starting height of the block, if the height interval of the block to be updated is greater than 1 according to the unit synchronization block information, it means that multiple blocks need to be updated at a time, and the determined target block information can be the height interval of the block to be updated. The starting point of the height interval of the block to be updated is the starting height of the block, and the end point can be determined according to the starting height of the block and the height of the number of blocks in the interval. Among them, the node to be synchronized can only update one block at a time, and the node to be synchronized can also update multiple blocks at a time. Whether to update only one block at a time or to update multiple blocks at a time can be determined in combination with factors such as the performance of the blockchain network, network conditions, and data capacity. The number of shard synchronization nodes may be the number of nodes for data sharding of unit synchronization block information. The number of shard synchronization nodes may be related to the amount of data in the block height interval to be updated represented by the unit synchronization block information. If the amount of data in the height interval to be updated is larger, the number of shard synchronization nodes may be relatively larger, thereby improving the efficiency of block synchronization. If the amount of data in the height interval to be updated is smaller, the number of shard synchronization nodes may be relatively smaller, thereby reducing the resources occupied by block synchronization. Data byte sharding may be a process of processing unit synchronization block information based on the number of shard synchronization nodes to obtain block information shards that match the number of shard synchronization nodes. Each unit synchronization block information may be divided into the same number of block information shards as the number of shard synchronization nodes. For each block information shard, each consensus node may be configured separately.

[0141] Specifically, the computer device can perform data byte sharding on the target block information according to the number of shard synchronization nodes, and obtain block information shards of the same number as the number of shard synchronization nodes. Furthermore, the computer device determines, from the blockchain network, the consensus nodes that match the block information shards respectively based on the obtained block information shards. For example, if the computer device determines a total of 3 block information shards, namely block information shard 1, block information shard 2, and block information shard 3, the computer device must determine, from the blockchain network, consensus node 1 that matches block information shard 1, consensus node 2 that matches block information shard 2, and consensus node 3 that matches block information shard 3.

[0142] In a specific implementation, when the node to be synchronized updates multiple blocks each time, the starting height of the block is 1, the height interval of one update is 12, and the target block information is determined to be 1-12, indicating that the blocks from block height 1 to block height 12 need to be updated, and the number of shard synchronization nodes is 3. The computer device can divide the target block information 1-12 according to the number of shard synchronization nodes 3 to obtain 3 block information shards. Among them, when the computer device divides the block information shards, it can be evenly divided according to the number of distributed synchronization nodes, so that the data byte length corresponding to each obtained block information shard is the same, that is, the block height interval of block information shard 1 is 1-4, that is, the block height interval of block information shard 1 is 5-8, the block height interval of block information shard 2 is 1-4, that is, the block height interval of block information shard 3 is 9-12. The computer device determines, for block information shard 1, a consensus node 1 with a block height of at least 4, for block information shard 2, a consensus node 2 with a block height of at least 8, and for block information shard 3, a consensus node 3 with a block height of at least 12.

[0143] In this embodiment, the computer device determines the target block information based on the block information to be synchronized and the unit synchronization block information, performs data byte sharding on the target block information, obtains the same number of block information shards as the number of shard synchronization nodes, and based on the obtained block information shards, can accurately determine from the blockchain network the various consensus nodes that match the block information shards.

[0144] In one embodiment, according to the block information to be synchronized, the number of nodes of the consensus nodes and the block shard index information of each consensus node, a shard push request configured for each consensus node is generated, including: determining the number of nodes of the consensus node; determining the block shard index information of each consensus node according to the number of nodes; the block shard index information of each consensus node is different from each other; based on the block information to be synchronized, the number of nodes of the consensus nodes and the block shard index information of each consensus node, a shard push request configured for each consensus node is generated; the shard push request is used to instruct the receiving consensus node to continuously return the specified shard data.

[0145] Specifically, the computer device can determine the number of consensus nodes based on the determined consensus nodes, and determine the block shard index information corresponding to each consensus node according to the number of nodes. The number of block shard index information can match the number of consensus nodes. For example, if there are 10 consensus nodes, the number of block shard index information can be 10. For different consensus nodes, the corresponding block shard index information can also be different. For example, for consensus node 1, the corresponding block shard index information is index 1, and for consensus node 2, the corresponding block shard index information is index 2. The computer device can generate a push stream protocol for each consensus node in combination with the synchronization block information, the number of consensus nodes, and the block shard index information of each consensus node, and send each push stream protocol to the corresponding consensus node, so as to instruct the consensus node to return the block data. Among them, after the consensus node returns the specified shard data for the block to be synchronized determined by the block information to be synchronized, it can continue to return the specified shard data based on the next block to be synchronized of the current block to be synchronized according to the node number and block shard index information of the consensus node in the push protocol, so that the push protocol can instruct the consensus node to continue to return the specified shard data, which is conducive to reducing the number of times the block synchronization request is sent. For example, the block to be synchronized is a block with a block height of 9. After each consensus node returns the specified shard data for the block with a block height of 9, it can continue to combine the node number and block shard index information of the consensus node to return the specified shard data for the block with a block height of 10. For another example, the current block to be synchronized is a block with a block height interval of 1-3. After each consensus node returns the specified shard data for the block with a block height interval of 1-3, it can continue to combine the node number and block shard index information of the consensus node to return the specified shard data for the block with a block height interval of 4-6.

[0146] In this embodiment, the computer device sends a shard request to each consensus node, and the consensus node can continuously return the specified shard data through the information carried in the shard push request, which is conducive to reducing the number of times the block synchronization request is sent, thereby improving the synchronization efficiency of blocks in the blockchain.

[0147] In one embodiment, block synchronization is performed for the nodes to be synchronized according to the designated shard data returned by each consensus node, including: extracting block data and marking information from the designated shard data returned by each consensus node; assembling the block data belonging to the same block to be synchronized returned by each consensus node in sequence according to the extracted marking information to obtain the data to be synchronized that matches the block to be synchronized; and performing block synchronization for the nodes to be synchronized in turn based on each data to be synchronized.

[0148] Among them, the marking information refers to the information used to identify each designated shard data. The marking information can be any symbol that can be used for identification, such as letters, numbers, and feature codes, as long as different designated shard data can be distinguished. The block data can be the actual data in the designated shard data that can be used for block synchronization. The block data belonging to the same block to be synchronized are assembled in sequence, which can mean that the block data belonging to the same block to be synchronized are assembled into a complete data to be synchronized according to the order of each consensus node.

[0149] Specifically, the identification information can be located at the head of the specified shard data, and the computer device can identify the head of the specified shard data. The length of the head can be fixed to 4 bytes. Therefore, the computer device can identify the 4 bytes of the head of the specified shard data, thereby determining the block to be synchronized to which the block data in the specified shard data belongs. For example, if it is identified that the identification information of block data 1 and block data 2 is the same, it can be indicated that block data 1 and block data 2 belong to block 1 to be synchronized, and the identification information of block data 3, block data 4 and block data 5 is the same, which can be indicated that block data 3, block data 4 and block data 5 belong to block 2 to be synchronized. By setting the identification information, it can be ensured that block data belonging to different blocks to be synchronized will not be assembled together. Furthermore, when the computer device assembles the block data belonging to the same block to be synchronized, it can assemble the block data returned by the corresponding consensus nodes in sequence according to the consensus node order when configuring the consensus, thereby obtaining complete data to be synchronized. For the data to be synchronized that matches each block to be synchronized, the computer device can sequentially perform block placement according to the block height sequence corresponding to the block to be synchronized, wherein the block height sequence can be determined by the position of the block information to be distributed where the block to be synchronized is located.

[0150] In this embodiment, the computer device assembles the block data belonging to the same block to be synchronized according to the marking information of the specified shard data, obtains the data to be synchronized, and performs block synchronization in sequence according to the matching data to be synchronized of each block to be synchronized. This not only improves the block landing speed of each block to be synchronized, but also makes the block landing and synchronization more balanced.

[0151] In one embodiment, block synchronization is performed on the node to be synchronized according to the designated shard data returned by each consensus node, including: obtaining at least one data to be synchronized that matches the block to be synchronized according to the block falling order according to the designated shard data returned by each consensus node; and performing block synchronization on the node to be synchronized according to the block falling order through the data to be synchronized that matches the at least one block to be synchronized.

[0152] Specifically, the block placement order can be the set order for submitting the data to be synchronized to the database of the node to be synchronized. When the data to be synchronized of the block to be synchronized is submitted to the database of the node to be synchronized, it means that the block synchronization has been completed for the block to be synchronized. The block placement order can be determined according to the position of the block to be synchronized on the main chain of the block. The closer the position of the block to be synchronized on the main chain, the earlier the block placement order of the data to be synchronized that matches the block to be updated. With respect to the data sharding method, since each block may be sharded separately, the node to be synchronized can obtain at least one data to be synchronized that matches the block to be synchronized. Accordingly, the node to be synchronized can submit the data to be synchronized of the block to be synchronized to the database to complete the block synchronization.

[0153] In the above embodiment, after obtaining the data to be synchronized that matches at least one block to be synchronized, the node to be synchronized will submit the data to be synchronized of at least one block to be synchronized to the database in sequence according to the block landing order, complete the block synchronization, and ensure the continuity of block synchronization.

[0154] In one embodiment, the blockchain block synchronization method also includes: when the node update condition is met, performing node update on each consensus node to obtain an updated consensus node; the blocks included in each updated consensus node are matched with the block information to be synchronized respectively; using the updated consensus node as each consensus node, and executing the step of generating a shard push request configured for each consensus node according to the block information to be synchronized, the number of nodes of the consensus node, and the block shard index information of each consensus node.

[0155] Among them, the node update condition refers to the set condition for updating the determined consensus nodes. The update of the consensus nodes can be specifically reflected in the change in the number of consensus nodes. If the number of consensus nodes increases, it means that new consensus nodes have been added to participate in block synchronization. If the number of consensus nodes decreases, it means that at least one consensus node has been removed. Of course, the number of consensus nodes may not change, such as when some consensus nodes are replaced, the number of consensus nodes remains unchanged. The node update condition can be determined in combination with the synchronization status of the block synchronization process, or it can be directly determined according to the update cycle.

[0156] Specifically, when the node update conditions are met, the computer device can add new consensus nodes to participate in the block synchronization to increase the number of consensus nodes; it can also remove some offline consensus nodes to reduce the number of consensus nodes, and it can also replace some consensus nodes while keeping the number of existing consensus nodes unchanged to obtain better consensus nodes, and it can also find new consensus nodes to replace the offline consensus nodes after removing some offline consensus nodes, so as to obtain updated consensus nodes. Of course, no matter how the number of consensus nodes changes, it is necessary to ensure that the block heights included in the consensus nodes as a whole can cover the starting height of the block to be synchronized corresponding to the block information to be synchronized. Based on the updated consensus node, the computer device returns to execute the step of generating a shard push request configured for each consensus node according to the block information to be synchronized, the number of nodes of the consensus node, and the block shard index information of each consensus node, that is, based on the updated consensus node, reconfigure and push the shard request to achieve block synchronization. In a specific application, if the current number of consensus nodes is 8, when the node update conditions are met, the node to be synchronized can update the number of consensus nodes, such as updating the current number of consensus nodes to 9, and regenerating the shard push request based on the 9 consensus nodes.

[0157] In one embodiment, when determining whether there is a consensus node that is offline, the computer device can determine that consensus node 1 is an offline node if the block data fed back by consensus node 1 is not received within 5 minutes. For another example, when verifying the block data fed back by consensus node 2, if the block data is incomplete, consensus node 2 is determined to be an offline node. At this time, the node to be synchronized can remove the offline node, and at the same time, it can determine whether it is necessary to find a substitute node to supplement the position of the offline node in combination with the degree of influence of the offline node on block synchronization, so as to update the consensus node. When the node update cycle is reached, such as the node update cycle is 10 minutes, when the block synchronization time reaches 10 minutes, it is determined that the node update cycle is reached, and the node to be synchronized can determine the updateable node from the blockchain network, and perform node updates for each consensus node through the updateable node. If a consensus node returns block data slowly, and the blocks included in the updateable node are synchronized with the blocks included in the consensus node, the node to be synchronized can use the updateable node to replace the consensus node.

[0158] In this embodiment, when the computer device determines that the node update conditions are met, it will perform node updates on each consensus node, obtain updated consensus nodes, and generate shard push requests based on the updated consensus nodes, thereby dynamically adjusting the number of consensus nodes, which can improve the flexibility of block synchronization.

[0159] In one embodiment, Figure 8As shown, a blockchain block synchronization method is provided, which is executed by a blockchain node in a blockchain network, and can be specifically executed by a consensus node. In the embodiment of the present application, the method is applied to a computer device corresponding to a consensus node as an example for explanation, and includes the following steps:

[0160] Step 802, receiving a shard push request sent by a node to be synchronized in the blockchain network; the shard push request includes determining the block information to be synchronized for the node to be synchronized, the number of consensus nodes, and the block shard index information.

[0161] Specifically, the consensus node can obtain the shard push request sent by the node to be synchronized, and the shard push request may include information about the block to be synchronized for the node to be synchronized, the number of nodes of the consensus node, and the block shard index information. The block information to be synchronized can be determined according to the actual situation of the node to be synchronized, and specifically can be the starting height of the block to be synchronized. The number of nodes of the consensus node can be determined according to the consensus node actually determined. The block shard index information can be information used to determine the shard data pushed by each consensus node. According to the block shard index information, the shard data that the consensus node needs to feedback can be determined.

[0162] Step 804, based on the information of the blocks to be synchronized, determine the blocks to be synchronized for the nodes to be synchronized, and divide the blocks to be synchronized into slices according to the number of nodes to obtain data of each slice.

[0163] The shard data is the data obtained by sharding the block to be synchronized according to the number of nodes in the shard push request. Specifically, the consensus node can determine the block to be synchronized based on the information of the block to be synchronized, and divide the block to be synchronized to obtain the shard data, wherein the number of shard data is related to the number of nodes, and the data volume of the shard data, that is, the data byte length is related to the number of blocks to be synchronized. The block to be synchronized may include only one block or multiple blocks. In one embodiment, Fig. 9As shown, the block information to be synchronized is numbered 1-100, and the block height is 100. Data sharding 902 corresponds to the process of sharding each block respectively. Therefore, when the block height is 100, the consensus node can obtain 100 block information segments to be sharded, and shard each block information segment to be sharded in turn. For example, for the first block information segment to be sharded, the consensus node can perform data sharding from the horizontal dimension to obtain multiple block sharding information corresponding to the first block information segment to be sharded. Block segmentation 904 corresponds to the process of sharding a block composed of multiple blocks. In this embodiment, 10 blocks constitute a block as a whole. When the block height is 100, the consensus node can obtain 10 block information segments to be sharded, and shard these 10 block information segments to be sharded in turn. For the information segment to be sharded composed of multiple blocks, the consensus node can also perform data sharding from the horizontal dimension to obtain multiple block sharding information corresponding to the block as a whole.

[0164] Step 806, determining the designated shard data matching the block shard index information from each shard data.

[0165] Among them, the designated shard data is the shard data that matches the block shard index information among the shard data obtained by shard division. Specifically, the consensus nodes correspond to the block shard index information respectively. For example, for consensus node 1 and consensus node 2, consensus node 1 can correspond to block shard index 1, and consensus node 2 can correspond to block shard index 2. In the case of two consensus nodes, the consensus nodes can shard the block to be synchronized and obtain two shard data, namely shard data 1 and shard data 2. According to the block shard index information, shard data 1 is the designated shard data corresponding to consensus node 1, and shard data 2 is the designated shard data corresponding to consensus node 2.

[0166] Step 808, push the specified shard data to the node to be synchronized; the specified shard data is used to instruct the node to be synchronized to perform block synchronization based on the specified shard data.

[0167] Specifically, the consensus node can return its corresponding designated shard data to the node to be synchronized, and the node to be synchronized will perform block synchronization based on the designated shard data. After receiving the designated shard data pushed by each consensus node, the node to be synchronized can sequentially splice the designated shard data according to the block shard index information of each consensus node to obtain the data of the complete block to be synchronized, and perform block synchronization based on the data of the complete block to be synchronized.

[0168] The above-mentioned blockchain block synchronization method receives a shard push request sent by a node to be synchronized in a blockchain network, which includes determining the block information to be synchronized for the node to be synchronized, the number of nodes of the consensus node, and the block shard index information, determining the block to be synchronized for the node to be synchronized based on the block information to be synchronized, and dividing the block to be synchronized into shards according to the number of nodes, obtaining each shard data, determining the designated shard data matching the block shard index information from each shard data, and pushing the designated shard data to the node to be synchronized to instruct the node to be synchronized to perform block synchronization based on the designated shard data. In the process of blockchain block synchronization, the designated shard data is pushed to the node to be synchronized based on the received shard push request, so that the node to be synchronized can perform block synchronization according to the designated shard data returned by each consensus node, and multiple consensus nodes can be effectively scheduled for block synchronization, thereby improving the synchronization efficiency of blocks in the blockchain.

[0169] In one embodiment, the block information to be synchronized includes the starting height of the block to be synchronized for the node to be synchronized; based on the block information to be synchronized, the block to be synchronized for the node to be synchronized is determined, and the block to be synchronized is divided into shards according to the number of nodes to obtain data of each shard, including: determining unit synchronization block information for the node to be synchronized; based on the starting height of the block to be synchronized and the unit synchronization block information, determining at least one block to be synchronized for the node to be synchronized in the blocks stored on the local end; dividing at least one block to be synchronized into shards according to the number of nodes to obtain data of each shard matching the number of nodes.

[0170] The unit synchronization block information may be information describing the height of the block that needs to be updated by the synchronization node each time. The consensus node may determine the block to be synchronized for the synchronization node in combination with the block starting height and the unit synchronization block information, wherein the synchronization node may only update one block at a time, or may update multiple blocks at a time. Sharding may be a process of processing the synchronization block based on the number of nodes to obtain shard data that matches the number of nodes. Each synchronization block may be divided into the same number of shard data as the number of nodes, and each shard data may be synchronized for a consensus node.

[0171] Specifically, the computer device can determine the blocks to be synchronized for the nodes to be synchronized according to the block starting height and the unit synchronization block information. The blocks to be synchronized can specifically include one or more blocks. The computer device divides the entire block to be synchronized into shards based on the number of nodes. Specifically, the entire block to be synchronized can be divided into shards according to the byte data granularity to obtain the same number of shard data as the number of nodes. Furthermore, each consensus node can respectively determine the designated shard data that matches each other and feed it back to the node to be synchronized.

[0172] In this embodiment, the consensus node performs data byte sharding on the block to be synchronized according to the number of nodes, and obtains the same number of block data as the number of nodes, so that the block data can be efficiently fed back to the node to be synchronized.

[0173] The present application also provides an application scenario, which applies the above-mentioned blockchain block synchronization method. Specifically, the application of the blockchain block synchronization method in the application scenario is as follows:

[0174] With the development of computer technology, blockchain has attracted more and more attention and applications due to its characteristics of decentralization, information immutability, autonomy, etc. In order to enable each blockchain node on the blockchain to participate in the normal consensus process, it is necessary to synchronize the blocks of the nodes on the blockchain whose block height lags behind the latest block height in the network.

[0175] At present, the implementation scheme of block synchronization in the industry basically selects a synchronization node to synchronize in sequence according to the block height in order to ensure the continuity of the block. Fig.10 As shown in the figure, the main steps of the synchronization mechanism in the industry are as follows: when a new node joins the blockchain network, it determines whether its own height is the latest. If it is the latest block height, it will not be processed, that is, the processing is completed; if it is not the latest, that is, when its own height is lower than the latest block height on the chain, it calculates the latest height that can be synchronized, and then randomly selects a consensus node, or selects a super node to initiate a synchronization request to the node. After receiving the synchronization block from the consensus node, the block transaction data is verified. After the verification is passed, the block is submitted to the local database. Super node: In some blockchain networks, some consensus nodes have a higher level of authority than other nodes for some reasons, such as higher equity or some kind of certification. This type of node is usually more credible and usually has more voting rights in the blockchain network.

[0176] The current implementation scheme for block synchronization in the industry has obvious shortcomings. If a new node lags behind many blocks, especially a blockchain network that has been running for a long time, or a network with a very high block generation efficiency, it will still lag behind many blocks after the node is restarted. If this blockchain network uses the traditional block synchronization method, the efficiency is very low. If a situation occurs: the efficiency of synchronizing blocks is lower than the efficiency of new blocks in the blockchain network, then it will be difficult for the new node to catch up with the speed of the blockchain network.

[0177] Based on this, the blockchain block synchronization method provided in this embodiment aims at the performance problem of block synchronization. When the block synchronization connection has been established, the new node does not need to send information such as the height and number of blocks to be synchronized to the consensus node. All consensus nodes that have established connections can continuously push shard data to the new node according to the protocol information carried when the connection is established, thereby reducing the number of synchronization requests sent by the new node to the consensus node. The blockchain block synchronization method provided in this embodiment is effective not only for block synchronization in the blockchain, but also for situations where other modules such as the transaction pool have similar scenarios.

[0178] Different from traditional synchronization, synchronization based on data sharding is to send the synchronization request to multiple consensus nodes for the same block or the same batch of blocks during synchronization. Each consensus node divides the data into multiple fragments according to the sharding strategy, and then sends the corresponding sharding data according to the index value after the node is sorted. When the new node receives the data sent by multiple consensus nodes, it reorganizes the data according to the sharding strategy to complete the synchronization of this block or this batch of blocks. Among them, data sharding: each consensus node that receives the synchronization request will shard a group of block data, which can include multiple blocks, such as blocks 1-100, or only one block, one by one according to the number of consensus nodes that can be synchronized. After each node is sorted according to the node ID, the corresponding sharding index is assigned. Sharding strategy: Each shard includes two parts: sharding header and sharding content. The header marks the segment to which the sharding data belongs. The header length is fixed to 4 bytes, and the content is the actual sharding data content. The consensus node shards the segmented data according to its own shard index, takes out the shard of the corresponding index, assembles the data header, and sends the data to the new node. Data reorganization: When the new node receives all the shards of the same segment, it starts data assembly. The 4 bytes of the header of each shard are used to identify the segment to which the current shard belongs, and then the content after removing the header is spliced ​​into a complete data in the order of the shards. Block drop: After the data is assembled, the blocks are dropped in sequence according to the block height order within the segment. Block drop: means writing the block to the local storage of the blockchain. Segmentation: When data synchronization is performed according to batch block synchronization, such as blocks 1-100 are a segment, that is, these 100 blocks are synchronized together.

[0179] like Fig.11As shown in the figure, it is a flowchart corresponding to data shard synchronization, which specifically includes: the blocks that need to be synchronized are 1-10, and the consensus nodes include consensus node 1, consensus node 2, consensus node 3 and consensus node 4, a total of 4 consensus nodes. For each consensus node, after each consensus node is sorted, the corresponding shard index is assigned, and the shards are corresponding to the number of consensus nodes that can be synchronized one by one, and the shard index 1 (slice1), shard index 2 (slice2), shard index 3 (slice3) and shard index 4 (slice4) are obtained. Fig.12 In the example, consensus node 1 corresponds to shard index 1, consensus node 2 corresponds to shard index 2, etc. After consensus nodes 1-4 complete the synchronization of their respective data allocations, the data of blocks 1-10 are obtained based on the data combination of each shard, and the new node performs block synchronization processing for them.

[0180] Consensus node 1 can synchronize shard 1 to a new node based on shard index 1... Consensus node 4 can synchronize shard 4 to a new node based on shard index 4. Fig.12 As shown in the figure, each shard data includes two parts: data header and data body. Blocks 1-10 include data body 1, data body 2, data body 3 and data body 4. The header marks the segment to which the shard data belongs. The header length is fixed to 4 bytes, and the content is the actual shard data content. The consensus node shards the segment data according to its own shard index, takes out the shard of the corresponding index, assembles the data header, and sends the data to the new node.

[0181] like Fig.13 As shown in Figure 2, when the new node receives all the fragments of the same segment, Fig.13 There are three shards in the data. The data assembly starts. The 4 bytes of the header of each shard are used to identify the segment to which the current shard belongs. Then, the data body after removing the header is spliced ​​into a complete segmented data in the order of the shards. After the data is assembled, the blocks are placed in sequence according to the block height order in the segment. The block placement means writing the block to the local storage of the blockchain.

[0182] Furthermore, for data streaming, a consensus node optimization scheme responsible for streaming is proposed, that is, how to select a better consensus node from the blockchain network to complete block synchronization. Based on this optimization scheme, the synchronization function can still run stably with high performance in an unstable blockchain network.

[0183] Among them, when a new node is added to the blockchain network, the node manager module of the new node will receive heartbeat messages sent from other blockchain nodes that can synchronize blocks. The heartbeat message will be accompanied by the current block height of each blockchain node. When the new node establishes a connection, it will first prepare the push protocol, which will contain several important information: the number of consensus nodes responsible for pushing the stream, the index value corresponding to each node, that is, the data content of the shard to be sent, and the starting height of the block to start synchronization. When the push protocol is configured, it will send a connection request to all consensus nodes in the push protocol. If the connection is completed, these consensus nodes will start to send shard data according to the content of the protocol; if the connection fails, the consensus node will be kicked out of the list, and the protocol will be prepared again before trying to connect again. Among them, the node manager: the node manager is responsible for collecting information about blockchain nodes that can synchronize data. The information here mainly includes the current block height, synchronization stability parameters, and node status of the blockchain node. Push protocol: the push protocol is required when establishing a handshake for the connection. When the new node takes out a batch of consensus nodes in normal status from the node manager, it needs to prepare the data of the push streaming protocol before initiating a connection establishment request to the other consensus node. The push streaming protocol contains three important data: the starting height of the synchronization block; the total number of consensus nodes participating in the push streaming; the current consensus node is responsible for pushing the shard index index. Establishing a connection: Different from the TCP connection establishment, the push streaming connection here is based on the TCP protocol. Therefore, there is no need to go through operations such as three-way handshakes, you only need to send the push streaming protocol directly. When the consensus node receives the push streaming protocol, it can start sending shard data according to the push streaming protocol.

[0184] like Fig.14As shown, it is a flow chart of the push protocol from preparation to sending. Among them, three consensus nodes are maintained in the node list of the node manager, namely consensus node 1, consensus node 2 and consensus node 3. The new node can form a protocol sent to each consensus node for each consensus node, and store the protocol in the protocol list. For the push protocol sent to consensus node 1, the corresponding protocol content is: shard index = 1, number of consensus nodes = 3 and block starting height = 10, indicating that for the block to be synchronized with the block starting height = 10, three groups of shards can be obtained, and the shard index = 1 can indicate that consensus node 1 is responsible for pushing the first shard. For the push protocol sent to consensus node 2, the corresponding protocol content is: shard index = 2, number of consensus nodes = 3 and block starting height = 10, indicating that for the block to be synchronized with the block starting height = 10, three groups of shards can be obtained, and the shard index = 2 can indicate that consensus node 2 is responsible for pushing the second shard. For the push protocol sent to consensus node 3, the corresponding protocol content is: shard index = 3, number of consensus nodes = 3 and block starting height = 10, which means that for the block to be synchronized with block starting height = 10, three groups of shards can be obtained. Shard index = 3 can indicate that consensus node 3 is responsible for pushing the third shard.

[0185] The node manager can maintain the basic information and stability parameters of all blockchain nodes that can send blocks. The basic information mainly refers to the latest block height of the blockchain node. By comparing the height, it can be determined whether the blockchain node meets the basic data push requirements. The stability parameter represents the stability of the blockchain node in the network, thereby determining the consensus node from each blockchain node.

[0186] When preparing to push the streaming protocol, a batch of stable consensus nodes will be taken out from the node manager first to ensure that there will be no abnormalities in the synchronization of data after the connection is established. In the node manager, two consensus node lists are maintained: a stable list and an unstable list. Among them, the consensus nodes in the stable list all have very high stability parameters, and the standard of this stability parameter can be constrained by setting a configuration item. For example, the stability parameter threshold can be set to 95%, and blockchain nodes with a stability value exceeding 95% can be put into the stable node list, and nodes below this threshold are put into the unstable node list.

[0187] Among them, the node manager can maintain the basic information and stability parameters of all blockchain nodes that can send blocks through heartbeat broadcasters, heartbeat collectors, and network stability analyzers. A heartbeat broadcaster, a heartbeat collector, and a network stability analyzer are maintained in the node manager. They are used to broadcast their own height information, collect heartbeat information, and process and analyze heartbeat information. The block height of the node is to ensure that the selected consensus node height is higher than the receiving end in the node selection strategy, otherwise it is impossible to push higher block data. The network stability analyzer analyzes the stability coefficient of each consensus node based on information such as the heartbeat frequency and connectivity status of each consensus node.

[0188] like Fig.15 As shown in the figure, it is the internal structure block diagram of the node manager. It can be seen from the figure that the node manager includes a heartbeat broadcaster, a heartbeat collector, and a network stability analyzer. Among them, the heartbeat broadcaster is responsible for broadcasting its own node information at regular intervals, including block height, etc. The heartbeat receiver is responsible for receiving node information broadcasted by other nodes and forwarding it to the stability analyzer. The stability analyzer is responsible for analyzing the stability of each blockchain node. By analyzing the received node heartbeat messages, the stable list and unstable list are maintained.

[0189] like Fig.16 As shown, based on Fig.15 The flowchart of the node manager shown in the figure processes the received node heartbeat messages: other nodes in the blockchain network except the node to be synchronized can send heartbeat messages to the node manager. The heartbeat receiver in the node manager can receive the heartbeat messages sent by other nodes and send the heartbeat messages to the network stability analyzer for processing. The network stability analyzer records the heartbeat messages, calculates the stability, and updates the stable list and unstable list in the node manager.

[0190] The network stability analyzer is the core of the node manager, and its main function is to process and analyze the received heartbeat information. When a node is received by the network stability analyzer for the first time, it will be considered a stable node by default and put into the stable list; when a node's heartbeat information is not received for a period of time, it will be considered that the node is offline, a node offline event will be sent and the business layer will be notified, and the node will be removed from the stable node list and put into the unstable list.

[0191] like Fig.17As shown in the figure, it is a flowchart of the network stability analyzer maintaining the node list. If the network stability analyzer receives a heartbeat message from a certain node, it will accumulate the number of consecutive heartbeats associated with the node, that is, heartBeatTimes, to 1, and then compare heartBeatTimes with the set stable number stableTimes to see whether the stable parameter calculation conditions are met. If the stable parameter calculation conditions are not met, the process ends. If the stable parameter calculation conditions are met, the network stability analyzer can calculate the stable parameter and compare the stable parameter calculated at last with the set stable parameter threshold stableLine to determine whether the stable parameter reaches the stable parameter threshold. If the stable parameter threshold is reached, the node can be moved to the stable list. Among them, heartBeatTimes: represents the number of consecutive heartbeats so far. When no heartbeat information is received for a predetermined time, this value will be reset to 0. If the heartbeat can be received all the time, this value will continue to increase. stableTimes: stable number. When the heartBeatTimes of a node exceeds this value, it can participate in the stable parameter calculation. stableLine: stable parameter threshold. When the stable parameter calculated by the node exceeds the stable parameter threshold, it will be moved to the stable list. Among them, the stable parameter threshold is usually configured when a new node is started, such as 0.95, which means that more than 95% of the stable parameters can enter the stable list. The stableTimes stable times are also configured at startup, such as 100, which means that after 100 consecutive heartbeats, it can participate in the stable parameter calculation.

[0192] When calculating the stability parameters, the following stability parameter calculation formula can be used to expand the calculation:

[0193]

[0194] For example, if node 1 meets the conditions for calculating the stable parameter, and if node 1 has only been offline once and the number of consecutive heartbeats is 19, the stable parameter calculation formula is used, and the calculated stable parameter is: 19 / 20 = 95%. For another example, if node 2 meets the conditions for calculating the stable parameter, and if node 2 has only been offline 5 times and the number of consecutive heartbeats is 40, the stable parameter calculated by the stable parameter calculation formula is: 40 / 45 = 88%. When the stable parameter threshold is set to 95%, node 1 can be stored in the stable list, and node 2 can be stored in the unstable list.

[0195] like Fig.18The figure shows the flowchart of the network stability analyzer maintaining the node list. When the node heartbeat is not detected after a heartbeat cycle, the network stability analyzer will determine whether the heartbeat interval from the last heartbeat of the node to the present meets more than 2 heartbeat cycles. If so, the node will be offline. The offline operation includes: setting the number of consecutive heartbeats to 0; offline times offlineTimes+1, and moving to the unstable list. offlineTimes: offline times. Each time the node goes offline, this value will be increased by 1. This value will never be reset.

[0196] The work of providing a list of stable consensus nodes in the node manager can be completed by the node selector of the new node. The node selector does not simply take out all the stable lists maintained in the node manager at once, but on this basis, it will determine whether the number of consensus nodes in the stable list meets the basic requirements of shard push at this moment. For example: if there is only one consensus node or no consensus node in the current stable node list, an empty node list will not be returned. Therefore, at this time, 1-N consensus nodes will be selected from the unstable list and given to the upper layer to assemble the push protocol.

[0197] like Fig.19 As shown in the figure, it is the process of selecting nodes for the node selector: Among them, the stable list in the node manager can include nodes 1 and 2, and the unstable list can include nodes 3, 4 and 5. The node selector can first pull all stable consensus nodes from the stable list, that is, from the stable list. Since the shard push stream has certain requirements on the number of consensus nodes, it is necessary to determine the number of consensus nodes. If there are not enough stable consensus nodes in the stable list, a few are added from the unstable list, that is, the unstable list. The consensus nodes in the unstable list are obtained from high to low according to the stability parameters of the nodes.

[0198] The blockchain block synchronization method provided in this embodiment proposes a synchronization implementation method for data sharding and streaming, and the consensus node can continuously push sharding data to the new node, reducing the network communication of multiple requests. The blockchain block synchronization method provided in this embodiment can maintain a stable node list by calculating the stability of the node, so that the synchronization function can run on a relatively stable node, ensuring the continuous stability of synchronization.

[0199] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0200] Based on the same inventive concept, the embodiment of the present application also provides a blockchain block synchronization device for implementing the blockchain block synchronization method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in one or more blockchain block synchronization device embodiments provided below can refer to the limitations of the blockchain block synchronization method above, and will not be repeated here.

[0201] In one embodiment, Fig. 20 As shown, a blockchain block synchronization device 2000 is provided, including: an information acquisition module 2002, a consensus node determination module 2004, a shard push request generation module 2006 and a shard data acquisition module 2008, wherein:

[0202] The information acquisition module 2002 is used to determine the block information to be synchronized of the node to be synchronized in the blockchain network.

[0203] The consensus node determination module 2004 is used to determine each consensus node from the blockchain network based on the block information to be synchronized; the blocks included in each consensus node are matched with the block information to be synchronized.

[0204] The shard push request generation module 2006 is used to generate a shard push request configured for each consensus node according to the block information to be synchronized, the number of consensus nodes and the block shard index information of each consensus node.

[0205] The shard data acquisition module 2008 is used to send the configured shard push request to each consensus node respectively; the shard push request is used to instruct the receiving consensus node to return the specified shard data in the block to be synchronized determined based on the block information to be synchronized; the specified shard data is the shard data in each shard data that matches the block shard index information in the received shard push request; each shard data is obtained by the receiving consensus node dividing the block to be synchronized into shards according to the number of nodes;

[0206] The block update module 2010 is used to synchronize blocks for the nodes to be synchronized according to the designated shard data returned by each consensus node.

[0207] In one embodiment, the consensus node determination module 2004 is also used to obtain the node status information of each blockchain node in the blockchain network; based on the block information to be synchronized and the node status information of each blockchain node, each consensus node is screened from each blockchain node.

[0208] In one embodiment, the block information to be synchronized includes the starting height of the block to be synchronized for the node to be synchronized; the node status information includes the node block height and network stability parameters of the blockchain node to which it belongs; the consensus node determination module 2004 is also used to screen out candidate nodes from each blockchain node according to the node block height of each blockchain node; the node block height of the candidate node is not less than the starting height of the block to be synchronized; according to the network stability parameters of each candidate node, determine from the candidate nodes each consensus node whose network stability parameters meet the stability parameter screening conditions.

[0209] In one embodiment, the consensus node determination module 2004 is also used to obtain a stable node list constructed based on the network stability parameters of the candidate nodes; the stable node list includes candidate nodes whose network stability parameters are not less than the stability parameter threshold; and each consensus node is determined from the stable node list.

[0210] In one embodiment, the consensus node determination module 2004 is also used to obtain a supplementary node list when the number of stable nodes of the candidate nodes included in the stable node list is less than the required number of synchronization nodes for the node to be synchronized; the supplementary node list includes candidate nodes whose network stability parameters are less than the stability parameter threshold; the supplementary nodes are obtained from the supplementary node list according to the number of supplementary nodes; the number of supplementary nodes is determined based on the difference between the required number of synchronization nodes and the number of stable nodes; and each consensus node is obtained based on the candidate nodes included in the supplementary node list and the stable node list.

[0211] In one embodiment, the consensus node determination module 2004 is also used to obtain a stability parameter threshold and a network stability parameter of each candidate node; add candidate nodes whose network stability parameters are not less than the stability parameter threshold to the first node list to obtain a stable node list; add candidate nodes whose network stability parameters are less than the stability parameter threshold to the second node list to obtain a supplementary node list.

[0212] In one embodiment, the network stability parameter is obtained through a stability parameter determination step; the consensus node determination module 2004 includes a network stability parameter determination module; the network stability parameter determination module is used to receive the node heartbeat message sent by each blockchain node; based on the node heartbeat message sent by each blockchain node, statistics are performed to obtain the heartbeat statistical parameters of each blockchain node; based on the heartbeat statistical parameters, the network stability parameters of the associated blockchain node are determined.

[0213] In one embodiment, the heartbeat statistical parameters include the number of consecutive heartbeats and the number of offline times; the number of consecutive heartbeats indicates the number of consecutively received node heartbeat messages; the number of offline times indicates the number of times the node connection is interrupted; the network stability parameter determination module is also used to determine the network stability parameters of the associated blockchain node according to the number of consecutive heartbeats and the number of offline times when the number of consecutive heartbeats exceeds the consecutive number threshold.

[0214] In one embodiment, the blockchain node determination device also includes a broadcast message sending module; the broadcast message sending module is used to continuously send broadcast messages in the blockchain network through the node to be synchronized; the broadcast message is used to instruct each blockchain node in the blockchain network to respectively feedback the node heartbeat message; the network stability parameter determination module is also used to count the number of continuous receptions of the blockchain node associated with the received node heartbeat message, and obtain the number of continuous heartbeats of each blockchain node; the number of non-receptions of the blockchain nodes associated with the non-received node heartbeat message is counted, and the number of offline times of each blockchain node is obtained.

[0215] In one embodiment, the consensus node determination module 2004 is further used to determine the target block information according to the block information to be synchronized and the unit synchronization block information for the node to be synchronized; according to the number of shard synchronization nodes to be synchronized for the node to be synchronized, the target block information is sharded into data bytes to obtain each block information shard; based on each block information shard, each consensus node is determined from the blockchain network; the blocks included in each consensus node are matched with the block information shards respectively.

[0216] In one embodiment, the shard push request generation module 2006 is also used to determine the number of consensus nodes; determine the respective block shard index information for each consensus node according to the number of nodes; the block shard index information of each consensus node is different from each other; based on the block information to be synchronized, the number of consensus nodes and the block shard index information of each consensus node, generate a shard push request configured for each consensus node; the shard push request is used to instruct the receiving consensus node to continuously return the specified shard data.

[0217] In one embodiment, the block update module 2010 is further used to extract block data and marking information from the designated shard data returned by each consensus node; assemble the block data belonging to the same block to be synchronized returned by each consensus node in sequence according to the extracted marking information to obtain the data to be synchronized that matches the block to be synchronized; and perform block synchronization on the nodes to be synchronized in turn based on each data to be synchronized.

[0218] In one embodiment, the block update module 2010 is further used to obtain data to be synchronized that matches at least one block to be synchronized according to the specified shard data returned by each consensus node in the order in which the blocks fall; and perform block synchronization on the node to be synchronized according to the order in which the blocks fall through the data to be synchronized that matches at least one block to be synchronized.

[0219] In one embodiment, in one embodiment, the blockchain block synchronization device also includes a consensus node update module; the consensus node update module is used to update each consensus node when the node update condition is met to obtain an updated consensus node; the blocks included in each updated consensus node are matched with the block information to be synchronized respectively; the updated consensus nodes are used as each consensus node, and the steps of generating a shard push request configured for each consensus node are executed according to the block information to be synchronized, the number of nodes of the consensus node, and the block shard index information of each consensus node.

[0220] In one embodiment, Fig.21 As shown, a blockchain block synchronization device 2100 is provided, including: a shard push request receiving module 2102, a shard data determining module 2104, a designated shard data determining module 2106 and a designated shard data pushing module 2108, wherein:

[0221] The shard push request receiving module 2102 is used to receive the shard push request sent by the node to be synchronized in the blockchain network; the shard push request includes the information of the block to be synchronized for the node to be synchronized, the number of consensus nodes and the block shard index information.

[0222] The shard data determination module 2104 is used to determine the to-be-synchronized blocks for the to-be-synchronized nodes based on the to-be-synchronized blocks information, and divide the to-be-synchronized blocks into shards according to the number of nodes to obtain data for each shard.

[0223] The designated shard data determination module 2106 is used to determine the designated shard data matching the block shard index information from each shard data.

[0224] The designated shard data push module 2108 is used to push the designated shard data to the node to be synchronized; the designated shard data is used to instruct the node to be synchronized to perform block synchronization based on the designated shard data.

[0225] In one embodiment, the block information to be synchronized includes the starting height of the block to be synchronized for the node to be synchronized; the shard data determination module 2104 is also used to determine the unit synchronization block information for the node to be synchronized; based on the starting height of the block to be synchronized and the unit synchronization block information, at least one block to be synchronized for the node to be synchronized is determined in the blocks stored on the local end; at least one block to be synchronized is divided into shards according to the number of nodes to obtain each shard data matching the number of nodes.

[0226] Each module in the above-mentioned blockchain block synchronization device can be implemented in whole or in part by software, hardware and a combination thereof. Each of the above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory in the computer device in the form of software, so that the processor can call and execute the corresponding operations of each of the above modules.

[0227] In one embodiment, a computer device is provided. The computer device may be a server or a terminal. The internal structure diagram thereof may be as follows: Fig. 22 As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. Among them, the processor, the memory and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store block synchronization data. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a blockchain block synchronization method is implemented.

[0228] Those skilled in the art will understand that Fig. 22 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0229] In one embodiment, a computer device is further provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps in the above method embodiments when executing the computer program.

[0230] In one embodiment, a computer-readable storage medium is provided, storing a computer program, which implements the steps in the above method embodiments when executed by a processor.

[0231] In one embodiment, a computer program product is provided, including a computer program, which implements the steps in the above method embodiments when executed by a processor.

[0232] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards of relevant countries and regions.

[0233] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., but are not limited to this.

[0234] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0235] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A blockchain block synchronization method, characterized in that: The method comprises: Determine the block information to be synchronized of the node to be synchronized in the blockchain network; Determine each consensus node from the blockchain network based on the block information to be synchronized; the blocks included in each consensus node are matched with the block information to be synchronized respectively; Generate a shard push request configured for each of the consensus nodes according to the block information to be synchronized, the number of the consensus nodes, and the block shard index information of each of the consensus nodes; Sending a shard push request for each configuration to each of the consensus nodes; the shard push request is used to instruct the receiving consensus node to return the specified shard data in the block to be synchronized determined based on the block information to be synchronized; the specified shard data is the shard data in each shard data that matches the block shard index information in the received shard push request; the shard data is obtained by the receiving consensus node dividing the block to be synchronized into shards according to the number of nodes; According to the designated shard data returned by each of the consensus nodes, block synchronization is performed on the node to be synchronized.

2. The method according to claim 1, characterized in that: Determining each consensus node from the blockchain network based on the block information to be synchronized includes: Obtaining node status information of each blockchain node in the blockchain network; Based on the block information to be synchronized and the node status information of each of the blockchain nodes, each consensus node is obtained by screening from each of the blockchain nodes.

3. The method according to claim 2, characterized in that The block information to be synchronized includes the starting height of the block to be synchronized for the node to be synchronized; the node status information includes the node block height and network stability parameters of the blockchain node to which it belongs; The method of selecting and obtaining consensus nodes from each of the blockchain nodes based on the block information to be synchronized and the node status information of each of the blockchain nodes includes: According to the node block height of each of the blockchain nodes, a candidate node is selected from each of the blockchain nodes; the node block height of the candidate node is not less than the starting height of the block to be synchronized; According to the network stability parameters of the candidate nodes, respective consensus nodes whose network stability parameters satisfy the stability parameter screening condition are determined from the candidate nodes.

4. The method according to claim 3, characterized in that The determining, according to the network stability parameters of the respective candidate nodes, respective consensus nodes whose network stability parameters satisfy the stability parameter screening condition from the candidate nodes comprises: Acquire a stable node list constructed based on the network stability parameters of the candidate nodes; the stable node list includes candidate nodes whose network stability parameters are not less than a stability parameter threshold; Each consensus node is determined from the stable node list.

5. The method according to claim 4, characterized in that The method further comprises: When the number of stable nodes of the candidate nodes included in the stable node list is less than the required number of synchronization nodes for the node to be synchronized, a supplementary node list is obtained; the supplementary node list includes candidate nodes whose network stability parameters are less than the stability parameter threshold; Acquire supplementary nodes from the supplementary node list according to the number of supplementary nodes; the number of supplementary nodes is determined according to the difference between the required number of synchronization nodes and the number of stable nodes; According to the candidate nodes included in the supplementary node and the stable node list, each consensus node is obtained.

6. The method according to claim 4, characterized in that The method further comprises: Acquire the stability parameter threshold and the network stability parameter of each of the candidate nodes; Adding candidate nodes whose network stability parameters are not less than the stability parameter threshold to the first node list to obtain the stable node list; The candidate nodes whose network stability parameters are less than the stability parameter threshold are added to the second node list to obtain a supplementary node list.

7. The method according to claim 3, characterized in that The network stability parameter is obtained through a stability parameter determination step; The stability parameter determination step comprises: Receive a node heartbeat message sent by each of the blockchain nodes; Based on the node heartbeat messages sent by each of the blockchain nodes, statistics are respectively performed to obtain the heartbeat statistical parameters of each of the blockchain nodes; Based on the heartbeat statistical parameters, a network stability parameter of the associated blockchain node is determined.

8. The method according to claim 7, characterized in that The heartbeat statistical parameters include the number of consecutive heartbeats and the number of offline times; The number of consecutive heartbeats indicates the number of consecutively received node heartbeat messages; The offline times represent the times when the node connection is interrupted; The determining of the network stability parameters of the associated blockchain node based on the heartbeat statistical parameters includes: When the number of consecutive heartbeats exceeds a consecutive number threshold, a network stability parameter of the associated blockchain node is determined according to the number of consecutive heartbeats and the number of offline times.

9. The method according to claim 8, characterized in that Before receiving the node heartbeat message sent by each of the blockchain nodes, the method further includes: Continuously sending broadcast messages in the blockchain network through the node to be synchronized; the broadcast messages are used to instruct each of the blockchain nodes in the blockchain network to feed back node heartbeat messages respectively; The node heartbeat messages sent by each of the blockchain nodes are counted respectively to obtain the heartbeat statistical parameters of each of the blockchain nodes, including: Counting the number of consecutive receptions of the blockchain nodes associated with the received node heartbeat messages to obtain the number of consecutive heartbeats of each of the blockchain nodes; The number of unreceived nodes of the blockchain nodes associated with the node heartbeat message that have not been received is counted to obtain the number of offline times of each of the blockchain nodes.

10. The method according to claim 1, characterized in that Determining each consensus node from the blockchain network based on the block information to be synchronized includes: Determine target block information according to the block information to be synchronized and the unit synchronization block information for the node to be synchronized; According to the number of shard synchronization nodes to be synchronized with the node to be synchronized, the target block information is sharded into data bytes to obtain individual block information shards; Based on each of the block information shards, each consensus node is determined from the blockchain network; the blocks included in each of the consensus nodes are matched with the block information shards respectively.

11. The method according to claim 1, characterized in that: The generating, according to the block information to be synchronized, the number of the consensus nodes and the block shard index information of each consensus node, a shard push request configured for each consensus node, comprises: Determining the number of nodes of the consensus node; Determine the respective block shard index information for each of the consensus nodes according to the number of nodes; the respective block shard index information of each of the consensus nodes is different from each other; Based on the block information to be synchronized, the number of the consensus nodes and the block shard index information of each consensus node, a shard push request configured for each consensus node is generated; the shard push request is used to instruct the receiving consensus node to continuously return the specified shard data.

12. The method according to claim 1, characterized in that The step of performing block synchronization on the node to be synchronized according to the designated shard data returned by each of the consensus nodes includes: Extracting block data and marking information from the designated shard data returned by each of the consensus nodes; According to the extracted marking information, the block data belonging to the same block to be synchronized returned by each of the consensus nodes are assembled in order to obtain the data to be synchronized that matches the block to be synchronized; Based on each piece of data to be synchronized, block synchronization is performed on the nodes to be synchronized in turn.

13. The method according to any one of claims 1 to 12, characterized in that: The step of performing block synchronization on the node to be synchronized according to the designated shard data returned by each of the consensus nodes includes: According to the designated shard data returned by each of the consensus nodes, and in the order of block placement, at least one to-be-synchronized data matching the to-be-synchronized block is obtained; According to the block placement order, block synchronization is performed on the node to be synchronized through at least one to-be-synchronized block matching the to-be-synchronized data.

14. The method according to any one of claims 1 to 12, characterized in that: The method further comprises: When the node update condition is met, a node update is performed on each of the consensus nodes to obtain an updated consensus node; the blocks included in each of the updated consensus nodes are matched with the block information to be synchronized; The updated consensus node is used as each consensus node, and the step of generating a shard push request configured for each consensus node is performed according to the block information to be synchronized, the number of nodes of the consensus node, and the block shard index information of each consensus node.

15. A blockchain block synchronization method, characterized in that: The method comprises: Receiving a shard push request sent by a node to be synchronized in the blockchain network; the shard push request includes information about blocks to be synchronized, the number of consensus nodes, and block shard index information for the node to be synchronized; Determine the block to be synchronized for the node to be synchronized based on the block to be synchronized information, and divide the block to be synchronized into slices according to the number of nodes to obtain data of each slice; Determine, from the shard data, designated shard data that matches the block shard index information; The specified shard data is pushed to the node to be synchronized; the specified shard data is used to instruct the node to be synchronized to perform block synchronization based on the specified shard data.

16. The method according to claim 15, characterized in that The block information to be synchronized includes the starting height of the block to be synchronized for the node to be synchronized; The determining the to-be-synchronized blocks for the to-be-synchronized nodes based on the to-be-synchronized blocks information, and dividing the to-be-synchronized blocks into shards according to the number of nodes to obtain data of each shard, includes: Determining unit synchronization block information for the node to be synchronized; Based on the starting height of the block to be synchronized and the unit synchronization block information, determining at least one block to be synchronized for the node to be synchronized in the blocks stored on the local end; The at least one block to be synchronized is divided into pieces according to the number of nodes to obtain data of each piece that matches the number of nodes.

17. A blockchain block synchronization device, characterized in that: The device comprises: An information acquisition module is used to determine the block information to be synchronized of the node to be synchronized in the blockchain network; A consensus node determination module, used to determine each consensus node from the blockchain network based on the block information to be synchronized; the blocks included in each consensus node are matched with the block information to be synchronized respectively; A shard push request generation module, used to generate a shard push request configured for each of the consensus nodes according to the block information to be synchronized, the number of the consensus nodes, and the block shard index information of each of the consensus nodes; The shard data acquisition module is used to send a shard push request for each configuration to each of the consensus nodes; the shard push request is used to instruct the receiving consensus node to return the specified shard data in the block to be synchronized determined based on the block information to be synchronized; the specified shard data is the shard data in each shard data that matches the block shard index information in the received shard push request; the each shard data is obtained by the receiving consensus node dividing the block to be synchronized into shards according to the number of nodes; The block update module is used to synchronize blocks for the nodes to be synchronized according to the designated shard data returned by each of the consensus nodes.

18. A blockchain block synchronization device, characterized in that: The device comprises: A shard push request receiving module, used to receive a shard push request sent by a node to be synchronized in the blockchain network; the shard push request includes information about blocks to be synchronized, the number of consensus nodes, and block shard index information for the node to be synchronized; A shard data determination module, configured to determine the to-be-synchronized block for the to-be-synchronized node based on the to-be-synchronized block information, and to divide the to-be-synchronized block into shards according to the number of nodes to obtain data for each shard; A designated shard data determination module, used to determine the designated shard data matching the block shard index information from the shard data; The designated shard data pushing module is used to push the designated shard data to the node to be synchronized; the designated shard data is used to instruct the node to be synchronized to perform block synchronization based on the designated shard data.

19. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 16 are implemented.

20. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 16 are implemented.

Images