Block synchronization method and device, equipment, storage medium and product

Abstract

The embodiment of the invention discloses a block synchronization method and device, equipment, a storage medium and a product. The method comprises the steps that when it is detected that a local block chain copy meets a block synchronization condition, a synchronization node sends a negotiation request to a push node, and the push node detects whether a block indicated by block indication information in the negotiation request exists in the local block chain copy after obtaining the negotiation request, the method comprises the following steps: detecting a block to be synchronized by a pushing node, returning first response information to the synchronization node based on a detection result, if a negotiation result in the first response information indicates that the pushing node agrees to push the block needing to be synchronized, sending first configuration information to the pushing node, generating first pushing data by the pushing node through the first configuration information and the block needing to be synchronized, and sending the first pushing data to the synchronization node. And sending the first push data to the synchronization node. Therefore, before the synchronization block is requested, the synchronization node negotiates the block needing to be synchronized with the push node through the negotiation request, so that invalid requests caused by information asymmetry can be reduced, and the block synchronization efficiency is improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a block synchronization method, a block synchronization device, a computer device, a computer-readable storage medium, and a block synchronization product. Background Art

[0002] With the advancement of scientific and technological research, blockchain technology has developed rapidly. Distributed ledgers are one of the core technologies of blockchain technology. The synchronization nodes in the blockchain network can update the local blockchain copy by synchronizing blocks from the push nodes; for example, the synchronization nodes obtain the required synchronized blocks by sending synchronization requests to the push nodes. Studies have found that due to the information asymmetry between the synchronization nodes and the push nodes (for example, the synchronization nodes are not clear whether there are push restrictions on the data in the push nodes), the block synchronization efficiency is low; for example, during the block synchronization process, there are situations where the synchronization nodes send synchronization requests to the same push node multiple times due to information asymmetry, but no response is received. Summary of the invention

[0003] The embodiments of the present application provide a block synchronization method, apparatus, device, computer-readable storage medium and product, which can improve the efficiency of block synchronization.

[0004] On the one hand, an embodiment of the present application provides a block synchronization method, including:

[0005] When it is detected that the local blockchain copy meets the block synchronization condition, a negotiation request is sent to the push node, the negotiation request includes block indication information, the block indication information is used to indicate the block to be synchronized, and the block synchronization condition includes: the height of the local blockchain copy is lower than the height threshold;

[0006] Obtaining first response information returned by the push node, where the first response information includes a negotiation result corresponding to the negotiation request;

[0007] If the negotiation result indicates that the push node agrees to push the blocks that need to be synchronized, first configuration information is generated, where the first configuration information includes capacity information, and the capacity information is used to indicate the capacity of the block cache space;

[0008] The first push data is obtained from the push node through the first configuration information. The first push data carries the block data of the block to be synchronized. The data volume of the block data is determined by the push node based on the capacity information.

[0009] In the embodiment of the present application, when it is detected that the local blockchain copy meets the block synchronization condition, a negotiation request is sent to the push node, and the first response information returned by the push node is obtained. If the negotiation result indicates that the push node agrees to push the block to be synchronized, the first configuration information is generated, and the first push data is obtained from the push node through the first configuration information. The first push data carries the block data of the block to be synchronized. It can be seen that before requesting the synchronization of blocks, negotiating the blocks to be synchronized with the push node through the negotiation request can reduce invalid requests caused by information asymmetry, thereby improving the efficiency of block synchronization.

[0010] On the one hand, an embodiment of the present application provides a block synchronization method, including:

[0011] Obtaining a negotiation request sent by a synchronization node, where the negotiation request includes block indication information, where the block indication information is used to indicate a block to be synchronized;

[0012] Detect whether the block indicated by the block indication information exists in the local blockchain copy, and return first response information to the synchronization node based on the detection result, where the first response information includes a negotiation result corresponding to the negotiation request;

[0013] If it is agreed to push the blocks to be synchronized to the synchronization node, first configuration information sent by the synchronization node is obtained, where the first configuration information includes capacity information, and the capacity information is used to indicate the capacity of the block cache space;

[0014] The first push data is generated by the first configuration information and the blocks to be synchronized, and the first push data is sent to the synchronization node. The first push data carries the block data of the blocks to be synchronized, and the data volume of the block data is determined based on the capacity information.

[0015] In the embodiment of the present application, the negotiation request sent by the synchronization node is obtained, and the block indicated by the block indication information is detected in the local blockchain copy, and the first response information is returned to the synchronization node based on the detection result. If it is agreed to push the block to be synchronized to the synchronization node, the first configuration information sent by the synchronization node is obtained, and the first push data is generated through the first configuration information and the block to be synchronized, and the first push data is sent to the synchronization node. The first push data carries the block data of the block to be synchronized. It can be seen that before pushing the block, the first response information is used to inform the synchronization node whether it agrees to push the block to be synchronized, which can reduce invalid requests caused by information asymmetry, thereby improving the efficiency of block synchronization.

[0016] On the one hand, an embodiment of the present application provides a block synchronization device, the block synchronization device comprising:

[0017] A sending unit, configured to send a negotiation request to a push node when it is detected that the local blockchain copy meets the block synchronization condition, wherein the negotiation request includes block indication information, and the block indication information is used to indicate the block to be synchronized, and the block synchronization condition includes: the height of the local blockchain copy is lower than the height threshold;

[0018] An acquiring unit, configured to acquire first response information returned by the push node, where the first response information includes a negotiation result corresponding to the negotiation request;

[0019] A processing unit, configured to generate first configuration information if the negotiation result indicates that the push node agrees to push the blocks to be synchronized, the first configuration information including capacity information, the capacity information being used to indicate the capacity of the block cache space;

[0020] The acquisition unit is further used to acquire first push data from the push node through the first configuration information, where the first push data carries block data of the blocks to be synchronized, and the data volume of the block data is determined by the push node based on the capacity information.

[0021] In one implementation, the first configuration information further includes a first version identifier, and the first version identifier is used to identify the block indicated by the block indication information; the processing unit is used to obtain the first push data from the push node through the first configuration information, specifically for:

[0022] Sending first configuration information to the push node;

[0023] Obtaining second response information and the first pushed data returned by the push node, where the second response information includes a first verification identifier, and the first verification identifier is used to identify the block carried in the first pushed data;

[0024] If the first verification identifier matches the first version identifier, it is determined that the block data carried in the first pushed data is the block data of the block to be synchronized.

[0025] In one embodiment, the processing unit is used to send a negotiation request to the push node when it is detected that the local blockchain copy meets the block synchronization condition, specifically for:

[0026] When it is detected that the local blockchain copy meets the block synchronization conditions, the blocks to be synchronized are sharded to obtain N height intervals, which do not overlap with each other, and N is an integer greater than 1;

[0027] Generate M negotiation requests based on the N height intervals, the block indication information in each negotiation request is used to indicate at least one of the N height intervals, and M is an integer greater than 1 and less than or equal to N;

[0028] Send M negotiation requests to M push nodes.

[0029] In one embodiment, the M push nodes include a first push node and a second push node, and if the block of the first height interval is not successfully synchronized from the second push node, the processing unit is further used to:

[0030] Sending second configuration information to the first push node; the second configuration information includes a second version identifier and a second height interval; the first height interval is included in the second height interval, and the second version identifier is used to identify the block indicated by the second height interval;

[0031] Obtaining third response information and second pushed data returned by the first push node, where the third response information includes a second verification identifier, and the second verification identifier is used to identify a block carried in the second pushed data;

[0032] If the second verification identifier matches the second version identifier, it is determined that the block carried in the second pushed data is the block indicated by the second height interval;

[0033] The local blockchain copy is updated according to the second pushed data to obtain an updated local blockchain copy.

[0034] In one embodiment, the processing unit is further configured to:

[0035] When it is detected that the remaining capacity of the block cache space is less than the capacity threshold, an occupancy notification is sent to the push node, and the occupancy notification is used to instruct the push node to suspend pushing the blocks that need to be synchronized.

[0036] In one embodiment, the processing unit is further configured to:

[0037] In response to a notification condition being triggered, generating a capacity notification based on the current remaining capacity of the block cache space, the notification condition including any one of the following: the current moment matches the preset moment, and the change amount of the block cache space is detected to be greater than the change amount threshold; the change amount is used to indicate the difference between the current remaining capacity of the block cache space and the remaining capacity of the block cache space at the target moment;

[0038] Send capacity notification to push nodes;

[0039] The third push data returned by the push node is obtained, and the data volume of the block data carried by the third push data is determined by the push node based on the capacity notification.

[0040] In one embodiment, the first response information further includes load information, where the load information is used to indicate the current push workload of the push node; if the negotiation result indicates that the push node agrees to push the blocks to be synchronized, the processing unit is used to generate first configuration information, specifically for:

[0041] If the load information indicates that the current push workload of the push node is less than the workload threshold, the first configuration information is generated.

[0042] In one embodiment, the processing unit is further configured to:

[0043] When the end notification sent by the push node is obtained, the block synchronization ends, and the end notification includes the end code;

[0044] If the end code is a valid value, it is determined that the push node has completed the push of the required synchronized blocks;

[0045] If the end code is an invalid value, it is determined that the push node push is abnormal.

[0046] On the one hand, an embodiment of the present application provides a block synchronization device, the block synchronization device comprising:

[0047] An acquiring unit, configured to acquire a negotiation request sent by a synchronization node, wherein the negotiation request includes block indication information, and the block indication information is used to indicate a block to be synchronized;

[0048] A processing unit, configured to detect whether the block indicated by the block indication information exists in the local blockchain copy, and return first response information to the synchronization node based on the detection result, where the first response information includes a negotiation result corresponding to the negotiation request;

[0049] The acquiring unit is further configured to acquire first configuration information sent by the synchronization node if it is agreed to push the blocks to be synchronized to the synchronization node, the first configuration information including capacity information, and the capacity information is used to indicate the capacity of the block cache space;

[0050] The processing unit is also used to generate first push data through the first configuration information and the blocks to be synchronized, and send the first push data to the synchronization node. The first push data carries the block data of the blocks to be synchronized, and the data volume of the block data is determined based on the capacity information.

[0051] In one implementation, the first configuration information further includes a first version identifier, and the first version identifier is used to identify the block indicated by the block indication information; and the processing unit is further used to:

[0052] Generate a second response message based on the first version identifier, where the second response message includes a first verification identifier, where the first verification identifier is used to identify a block carried in the first pushed data;

[0053] Sending second response information to the synchronization node.

[0054] In one embodiment, the processing unit is further configured to:

[0055] Obtain second configuration information sent by the synchronization node, where the second configuration information includes a second version identifier and a height interval, where the second version identifier is used to identify the block indicated by the height interval;

[0056] If it is agreed to push the block indicated by the height interval to the synchronization node, a third response message is generated based on the second version identifier, and the third response message includes a second verification identifier, and the second verification identifier is used to identify the block carried in the second pushed data;

[0057] Generate second push data based on the block indicated by the height interval, and send the second push data and third response information to the synchronization node.

[0058] In one embodiment, the processing unit is further configured to:

[0059] When receiving the occupancy notification sent by the synchronization node, suspend pushing the blocks that need to be synchronized to the synchronization node.

[0060] In one embodiment, the processing unit is further configured to:

[0061] Get the capacity notification sent by the synchronization node. The capacity notification is generated by the synchronization node based on the current remaining capacity of the block cache space;

[0062] Determine the quantity threshold by synchronizing the current remaining capacity of the node's block cache space;

[0063] The block data of the blocks that the synchronization node needs to synchronize are packaged based on the quantity threshold to obtain third pushed data, where the amount of block data carried by the third pushed data is less than the quantity threshold;

[0064] The third push data is sent to the synchronization node.

[0065] In one embodiment, the processing unit is further configured to:

[0066] If the block push required by the synchronization node is completed, an end notification is sent to the synchronization node. The end notification includes an end code, which is a valid value.

[0067] If the block push required by the synchronization node is abnormal, an end notification is sent to the synchronization node. The end notification includes an end code, and the end code is an invalid value.

[0068] In one embodiment, the block indication information includes the block starting height and the number of blocks; the processing unit is further configured to:

[0069] If the number of blocks is an invalid value, when it is detected that there is an updated block in the local blockchain copy, fourth push data is sent to the synchronization node, and the fourth push data carries the block data of the updated block;

[0070] When the end notification sent by the synchronization node is obtained, stop pushing blocks to the synchronization node.

[0071] Accordingly, the present application provides a computer device, the computer device comprising:

[0072] a memory, wherein a computer program is stored in the memory;

[0073] The processor is used to load a computer program to implement the above block synchronization method.

[0074] Accordingly, the present application provides a computer-readable storage medium, which stores a computer program, and the computer program is suitable for being loaded by a processor and executing the above-mentioned block synchronization method.

[0075] Accordingly, the present application provides a computer program product or a computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device performs the above-mentioned block synchronization method.

[0076] In the embodiment of the present application, when it is detected that the local blockchain copy meets the block synchronization condition, the synchronization node sends a negotiation request to the push node. After obtaining the negotiation request, the push node detects whether there is a block indicated by the block indication information in the negotiation request in the local blockchain copy, and returns a first response message to the synchronization node based on the detection result. If the negotiation result in the first response message indicates that the push node agrees to push the block to be synchronized, the synchronization node sends the first configuration information to the push node. The push node generates the first push data through the first configuration information and the block to be synchronized by the synchronization node, and sends the first push data to the synchronization node. It can be seen that before requesting the synchronization block, the synchronization node negotiates the block to be synchronized with the push node through the negotiation request, which can reduce invalid requests caused by information asymmetry, thereby improving the efficiency of block synchronization. BRIEF DESCRIPTION OF THE DRAWINGS

[0077] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0078] Figure 1a A schematic diagram of the architecture of a data sharing system provided in an embodiment of the present application;

[0079] Figure 1b A schematic diagram of the structure of a blockchain provided in an embodiment of the present application;

[0080] Figure 1cA schematic diagram of a process of generating a block provided in an embodiment of the present application;

[0081] Figure 1d A block synchronization scene graph provided in an embodiment of the present application;

[0082] Figure 2 A flowchart of a block synchronization method provided in an embodiment of the present application;

[0083] Figure 3 A flowchart of another block synchronization method provided in an embodiment of the present application;

[0084] Figure 4 A schematic diagram of a protocol format provided for an embodiment of the present application;

[0085] Figure 5 A flowchart of another block synchronization method provided in an embodiment of the present application;

[0086] Figure 6 A flowchart of another block synchronization method provided in an embodiment of the present application;

[0087] Figure 7 A block data synchronization architecture diagram provided for an embodiment of the present application;

[0088] Figure 8 A schematic diagram of the structure of a block synchronization device provided in an embodiment of the present application;

[0089] Fig. 9 A schematic diagram of the structure of another block synchronization device provided in an embodiment of the present application;

[0090] Fig.10 A schematic diagram of the structure of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0091] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0092] The present application embodiment involves blockchain technology. The following is a brief introduction to the relevant terms and concepts of blockchain technology:

[0093] Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc. It 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, platform product service layer, and application service layer.

[0094] The blockchain network can be understood as a data sharing system 100. The data sharing system 100 refers to a system for sharing data between nodes. An exemplary structure of the data sharing system 100 can be found in Figure 1a ;like Figure 1a As shown, the data sharing system may include multiple nodes 1001, and the multiple nodes 1001 may refer to each client in the data sharing system. Each node 1001 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 in 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.

[0095] Each node in the data sharing system has a corresponding node identifier, 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. Each node can maintain a node identifier list as shown in the following table, and store the node name and node identifier 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; for example, the node identifier can also be a binary serial code (such as 110001110), and Table 1 only takes the IP address as an example for explanation:

[0096] Table 1

[0097] Node Name Node ID Node 1 xxx.xxx.xxx.xxx Node 2 yyy.yyy.yyy.yyy … … Node X (X is a positive integer) zzz.zzz.zzz.zzz

[0098] Each node in the data sharing system stores the same blockchain. The blockchain consists of multiple blocks, see Figure 1bThe 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.

[0099] When generating each block in the blockchain, see Figure 1c 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:

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

[0101] 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.

[0102] 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 according to the node identification of other nodes in the data sharing system. Other nodes verify the newly generated block and add the newly generated block to the blockchain stored in them after the verification is completed.

[0103] Based on the above-mentioned blockchain-related technologies, an embodiment of the present application provides a block synchronization solution that can improve the efficiency of block synchronization. Figure 1d A block synchronization scene graph provided in an embodiment of the present application, such as Figure 1dAs shown, the block synchronization scenario provided by the present application includes a synchronization node 101 and a push node 102, and the block synchronization scheme provided by the present application can be executed by the synchronization node 101 or the push node 102. Among them, the synchronization node 101 and the push node 102 can be specifically a terminal device or a server, and the terminal device can include but is not limited to: smart phones (such as Android phones, IOS phones, etc.), tablet computers, portable personal computers, mobile Internet devices (Mobile Internet Devices, referred to as MID), intelligent voice interaction devices, smart home appliances, vehicle terminals, aircraft, wearable devices, etc., and the present application embodiment does not limit this; the server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN (Content Delivery Network, content distribution network), and basic cloud computing services such as big data and artificial intelligence platforms, and the present application embodiment does not limit this.

[0104] It should be noted that Figure 1d The number of synchronization nodes 101 and push nodes 102 is only used as an example and does not constitute an actual limitation of the present application. The synchronization nodes 101 and push nodes 102 may be connected via wired or wireless means, and the present application does not limit this.

[0105] The general process of the block synchronization solution provided by this application is as follows:

[0106] (1) When it is detected that the local blockchain copy meets the block synchronization condition, the synchronization node 101 sends a negotiation request to the push node 102. The block synchronization condition includes: the height of the local blockchain copy is lower than the height threshold, and the height threshold is determined based on the current height of the blockchain in the blockchain network. In one embodiment, the synchronization node 101 periodically detects the height of the local blockchain copy and the height of the blockchain in the blockchain network. When it is detected that the height of the local blockchain copy is lower than the height of the blockchain in the blockchain network, it is determined that the local blockchain copy meets the block synchronization condition.

[0107] The negotiation request includes block indication information, which is used to indicate the blocks that need to be synchronized. In one embodiment, the block indication information includes the starting height of the block and the number of blocks; for example, if the block height is x and the number of blocks is 100, it means that the synchronization node 101 requests to synchronize blocks whose heights belong to [x, x+99]. When the number of blocks is an invalid value (such as a negative number or 0), it means that the synchronization node 101 requests to synchronize all blocks whose heights are not less than x, and when the blockchain copy in the push node 102 is updated (new blocks are added), the updated (newly added) blocks are pushed to the synchronization node 101.

[0108] (2) The push node 102 obtains the negotiation request sent by the synchronization node 101, and generates a first response message based on the local blockchain copy and the block indication information carried in the negotiation request. The first response message includes the negotiation result corresponding to the negotiation request.

[0109] In one embodiment, the push node 102 detects whether the block indicated by the block indication information exists in the local blockchain copy. If the block indicated by the block indication information exists in the local blockchain copy, it is determined whether the block indicated by the block indication information has any restrictions (such as data hiding, or data range restrictions, etc.). If the block indicated by the block indication information exists in the local blockchain copy, and there is no restriction on the block indicated by the block indication information, and the push node 102 agrees to push the block (indicated by the block data) required by the synchronization node 101, the push node 102 generates the first response information (the negotiation result corresponding to the negotiation request indicates that the push node 102 agrees to push the block required for synchronization); accordingly, if the block indicated by the block indication information does not exist in the local blockchain copy, or there is a restriction on the block indicated by the block indication information, or the push node 102 does not agree to push the block (indicated by the block data) required by the synchronization node 101 (such as the push node 102 is busy), the push node 102 generates the first response information (the negotiation result corresponding to the negotiation request indicates that the push node 102 does not agree to push the block required for synchronization). After generating the first response information, the push node 102 returns the first response information to the synchronization node 101.

[0110] (3) The synchronization node 101 obtains the first response information returned by the push node 102. If the negotiation result indicates that the push node 102 agrees to push the blocks to be synchronized, the synchronization node 101 sends the first configuration information to the push node 102.

[0111] In one embodiment, the synchronization node 101 generates a version identifier (such as a version number) and a configuration list associated with the block to be synchronized, and generates capacity information based on the capacity of the block cache space (currently available). The configuration list is used to indicate the relevant configurations in the block push process (such as the format of the block data, the sharding configuration, etc.). The configuration list may include one or more configuration items, and each configuration item may be stored in the form of a "key-value pair". The configuration items in the configuration list may be dynamically adjusted based on actual needs, and this application does not impose any restrictions on this. The version identifier is used to identify the block that the synchronization node 101 needs to synchronize (i.e., the block indicated by the block indication information); in addition, the version identifier can also be used to identify the relevant configurations in the block push process. Further, the synchronization node 101 packages the version identifier, the configuration list, and the capacity information to obtain the first configuration information, and sends the first configuration information to the push node 102.

[0112] (4) The push node 102 obtains the first configuration information sent by the synchronization node 101, and generates the first push data through the first configuration information and the blocks to be synchronized. Specifically, based on the first configuration information, the push node 102 pushes the configuration of the blocks to be synchronized to obtain the block data. After obtaining at least one block data, one or more block data are packaged to obtain the first push data; wherein the amount of block data carried in the first push data is determined based on the capacity information (i.e., the capacity of the block cache space of the synchronization node 101). After obtaining the first push data, the push node 102 sends the first push data to the synchronization node 101.

[0113] Optionally, after acquiring the first configuration information sent by the synchronization node 101, the push node 102 may also return a second response message to the synchronization node 101, the second response message including a first verification identifier, and the first verification identifier is used to identify the block carried in the first push data. For the synchronization node 101, if the first verification identifier matches the first version identifier, it is determined that the block carried in the first push data is the block to be synchronized.

[0114] Furthermore, after obtaining the first push data returned by the push node 102, the synchronization node 101 can update the local blockchain copy according to the block data carried in the first push data to obtain an updated local blockchain copy.

[0115] In the embodiment of the present application, when it is detected that the local blockchain copy meets the block synchronization condition, the synchronization node sends a negotiation request to the push node, obtains the first response information returned by the push node, and if the negotiation result indicates that the push node agrees to push the block to be synchronized, the first configuration information is sent to the push node, and the push node generates the first push data through the first configuration information and the block to be synchronized by the synchronization node, and the synchronization node obtains the first push data returned by the push node, updates the local blockchain copy according to the first push data, and obtains the updated local blockchain copy. It can be seen that before requesting the synchronization block, the synchronization node negotiates the block to be synchronized with the push node through the negotiation request, which can reduce invalid requests caused by information asymmetry, thereby improving the efficiency of block synchronization.

[0116] Based on the above block synchronization scheme, the embodiment of the present application proposes a more detailed block synchronization method. The block synchronization method proposed in the embodiment of the present application will be described in detail below with reference to the accompanying drawings.

[0117] See also Figure 2 , Figure 2 A flowchart of a block synchronization method provided in an embodiment of the present application, the block synchronization method can be executed by a computer device; for example, Figure 1d The synchronization node 101 shown in FIG.

[0118] like Figure 2 As shown, the block synchronization method may include the following steps S201 to S204:

[0119] S201. When it is detected that the local blockchain copy meets the block synchronization conditions, a negotiation request is sent to the push node.

[0120] The block synchronization condition includes: the height of the local blockchain copy is lower than the height threshold, and the height threshold is determined based on the current height of the blockchain in the blockchain network. In one embodiment, the computer device periodically detects the height of the local blockchain copy and the height of the blockchain in the blockchain network, and when it is detected that the height of the local blockchain copy is lower than the height of the blockchain in the blockchain network, it is determined that the local blockchain copy meets the block synchronization condition. In another embodiment, when the computer device detects that the height difference between the height of the local blockchain copy and the height of the blockchain in the blockchain network is greater than the difference threshold, it is determined that the local blockchain copy meets the block synchronization condition.

[0121] The negotiation request includes block indication information, which is used to indicate the blocks that the computer device needs to synchronize. In one embodiment, the block indication information includes the starting height of the block and the number of blocks; for example, if the block height is x and the number of blocks is 100, it means that the computer device requests to synchronize blocks with a height of [x, x+99]. When the number of blocks is an invalid value (such as a negative number or 0), it means that the computer device requests to synchronize (in the push node) all blocks with a height not less than x, and when the blockchain copy in the push node is updated (new blocks are added), the updated (newly added) blocks are pushed to the computer device.

[0122] S202: Obtain the first response information returned by the push node.

[0123] The first response information includes the negotiation result corresponding to the negotiation request. In the specific implementation process, the negotiation result corresponding to the negotiation request can be indicated by plain text or cipher text, or by a response code. In one embodiment, the negotiation result corresponding to the negotiation request can be indicated by a response code; if the response code is a valid value, the computer device determines that the negotiation result is: the push node agrees to push the required synchronized blocks; accordingly, if the response code is an invalid value, the computer device determines that the negotiation result is: the push node does not agree to push the required synchronized blocks.

[0124] Optionally, if the response code is an invalid value, the first response information may also include rejection information, which is used to indicate the reason for not agreeing to push the blocks that need to be synchronized; for example, when the identification code of the rejection information is 1, it indicates that the push node does not contain the blocks that need to be synchronized; when the identification code of the rejection information is 2, it indicates that there are permission restrictions on the blocks that need to be synchronized; when the identification code of the rejection information is 3, it indicates that the push node is currently busy.

[0125] It can be understood that indicating the negotiation result corresponding to the negotiation request through a response code can reduce the data volume of the first response information and improve data interaction efficiency compared to indicating the negotiation result corresponding to the negotiation request through plain text or cipher text.

[0126] S203: If the negotiation result indicates that the pushing node agrees to push the blocks that need to be synchronized, first configuration information is generated.

[0127] The first configuration information is used to indicate the relevant configuration in the block push process. The first configuration information includes capacity information, and the capacity information is used to indicate the capacity of the block cache space. In one embodiment, the computer device generates the capacity information based on the capacity of its own block cache space (currently available). The capacity information is packaged to obtain the first configuration information.

[0128] In another embodiment, the first configuration information (push setting) also includes a first version identifier (version) associated with the block to be synchronized, and the first version identifier is used to identify the block to be synchronized by the computer device (i.e., the block indicated by the block indication information). In addition, the first configuration information may also include a configuration list (setting_enty), and the configuration list is used to indicate the relevant configurations in the block push process (such as the format of the block data, the sharding configuration, etc.). The configuration list may include one or more configuration items, and each configuration item may be stored in the form of a "key-value pair (id: value)". The configuration items in the configuration list can be dynamically adjusted based on actual needs, and this application does not impose any restrictions on this. Furthermore, the computer device packages the first version identifier, the configuration list and the capacity information to obtain the first configuration information.

[0129] S204: Obtain first push data from the push node through the first configuration information.

[0130] The first push data carries the block data of the block to be synchronized, and the data volume of the block data is determined by the push node based on the capacity information in the first configuration information. It is understandable that if the first configuration information also includes a configuration list, the push node can send the first push data to the computer device according to the configuration indicated by the configuration list (such as according to the data format indicated by the configuration list).

[0131] In one embodiment, the first configuration information also includes a first version identifier, the computer device sends the first configuration information to the push node, and obtains the second response information and the first push data returned by the push node, the second response information includes a first verification identifier, the first verification identifier is used to identify the block carried in the first push data, if the first verification identifier matches the first version identifier, then it is determined that the block carried in the first push data is the block to be synchronized. In another embodiment, the computer device sends the first configuration information to the push node, and obtains the first push data from the push node.

[0132] Furthermore, the computer device updates the local blockchain copy according to the first pushed data to obtain an updated local blockchain copy.

[0133] In the embodiment of the present application, when it is detected that the local blockchain copy meets the block synchronization condition, a negotiation request is sent to the push node, and the first response information returned by the push node is obtained. If the negotiation result indicates that the push node agrees to push the block to be synchronized, the first configuration information is generated, and the first push data is obtained from the push node through the first configuration information. The first push data carries the block data of the block to be synchronized. It can be seen that before requesting the synchronization of blocks, negotiating the blocks to be synchronized with the push node through the negotiation request can reduce invalid requests caused by information asymmetry, thereby improving the efficiency of block synchronization.

[0134] See also Figure 3 , Figure 3 A flowchart of another block synchronization method provided in an embodiment of the present application, the block synchronization method can be executed by a computer device; for example, Figure 1d The synchronization node 101 shown in FIG. Figure 3 As shown, the block synchronization method may include the following steps S301 to S308:

[0135] S301. When it is detected that the local blockchain copy meets the block synchronization conditions, a negotiation request is sent to the push node.

[0136] In one embodiment, the computer device performs slicing processing on the blocks to be synchronized to obtain N height intervals, the N height intervals do not overlap with each other, and N is an integer greater than 1. M negotiation requests are generated based on the N height intervals, and the block indication information in each negotiation request is used to indicate at least one of the N height intervals, where M is an integer greater than 1 and less than or equal to N. After generating the M negotiation requests, the computer device sends the M negotiation requests to the M push nodes (one push node sends one negotiation request). For example, assuming that the height of the block to be synchronized belongs to [101, 200], the computer device performs slicing processing on the block to be synchronized to obtain height interval 1 [101, 140], height interval 2 [141, 170], and height interval 3 [171, 200]. The computer device generates negotiation requests 1-negotiation requests 3 based on height intervals 1-3, respectively, and sends negotiation requests 1-negotiation requests 3 to push nodes 1-3.

[0137] In one embodiment, the M push nodes include a first push node and a second push node. If the computer device fails to successfully synchronize the blocks of the first height interval from the second push node, the computer device determines the second height interval based on the height interval to which the blocks to be synchronized from the first push node belong and the first height interval. The height interval to which the blocks to be synchronized from the first push node belong and the first height interval are both included in the second height interval; for example, assuming that the height interval to which the blocks to be synchronized from the first push node belong is [100, 150] and the first height interval is [151, 180], the computer device determines that the second height interval is [100, 180]. After determining the second height interval, the computer device generates a second version identifier associated with the blocks in the second height interval, that is, the second version identifier is used to identify the blocks indicated by the second height interval. After obtaining the second height interval and the second version identifier, the computer device generates second configuration information based on the second height interval and the second version identifier, and sends the second configuration to the first push node.

[0138] Further, the computer device obtains the third response information and the second push data returned by the first push node, the third response information includes a second verification identifier, the second verification identifier is used to identify the block carried in the second push data, and if the second verification identifier matches the second version identifier, the computer device determines that the block carried in the second push data is the block indicated by the second height interval. After determining that the block data carried in the second push data is the block data to be synchronized, the computer device can update the local blockchain copy according to the second push data to obtain an updated local blockchain copy.

[0139] In another embodiment, the block indication information in the negotiation request (negotiate request) may include the negotiated starting block height (height) and the negotiated block number (num); for the negotiated block number, when the num value is a positive integer, it indicates the number of blocks that need to be synchronized; when the num value is 0, it indicates that there is no limit on the number of synchronized blocks; when the num value is other values ​​(such as negative numbers, non-integers, etc.), it indicates an invalid request. It is understandable that the block indication information can also be indicated in other ways; for example, by indicating through a height interval, which is not limited in this application.

[0140] S302: Obtain the first response information returned by the push node.

[0141] In one implementation, the negotiation request may be included in the negotiation protocol. In addition to the negotiation request, the negotiation protocol also includes a negotiation response (ie, first response information). The negotiation request and the negotiation response may be identified by different flags.

[0142] Figure 4A protocol format diagram provided in an embodiment of the present application. Figure 4 As shown, the protocol format includes: payload data length (lenght), which is used to indicate the length of the payload data in the protocol; protocol type (protocol), which is used to indicate the type of the protocol. In the present application, the type of the protocol may be a negotiation protocol, a configuration protocol (used to configure relevant parameters in the block push process, which may include initialization configuration, update configuration, and response to initialization / update configuration), a push protocol (used to indicate the push status, which may include data push and end push), and a window protocol (used to notify the current remaining amount of the block cache space, which may include capacity (window) update); a protocol flag (flag), which is used to identify items in the protocol; for example, for a negotiation protocol, the flag of a negotiation request may be x0, and the flag of a negotiation response may be x1; payload data (payload), which is used to store data corresponding to each item in the protocol. For example, assuming that the negotiation request is "xxxx" and its length is 4, the flag of the negotiation request is x0, and the negotiation protocol is expressed as "negotiate", then the negotiation request can be expressed in the protocol format as: [4,negotiate,x0,xxxx]; similarly, assuming that the negotiation response is "yyy" and its length is 3, and the flag of the negotiation response is x1, then the negotiation response (first response information) can be expressed in the protocol format as: [3,negotiate,x1,yyy].

[0143] S303: If the negotiation result indicates that the pushing node agrees to push the blocks that need to be synchronized, first configuration information is generated.

[0144] In one embodiment, the first response information (negotiate response) may include the load information (workload) and response code (code) of the push node; wherein the load information of the push node is used to indicate the push workload being processed by the push node, and the response code is used to indicate whether the push node agrees to push the blocks required for synchronization. Specifically, when the response code is a valid value (such as 0), it indicates that the push node agrees to push the blocks required for synchronization; correspondingly, when the response code is an invalid value (such as a non-0 value), it indicates that the push node refuses to push the blocks required for synchronization. In addition, for a computer device (synchronization node), if the push node agrees to push the blocks required for synchronization, it can be determined whether it is necessary to synchronize the required blocks from the push node based on the push workload being processed by the push node. Specifically, if the load information indicates that the current push workload of the push node is less than the workload threshold, the first configuration information is generated; correspondingly, if the load information indicates that the current push workload of the push node is greater than or equal to the workload threshold, the synchronization of block data from the push node is abandoned (synchronizing blocks from other push nodes).

[0145] It can be seen that during the negotiation process, computer devices can flexibly select the push node for synchronization blocks based on the push workload being processed by the push node, thereby further improving the efficiency of block synchronization.

[0146] S304: Obtain first push data from the push node through the first configuration information.

[0147] In one embodiment, the first push data (push data) may include a block height (height), a first verification identifier (setting_version) and block data (data); wherein the block height is used to indicate the starting height of the pushed block, and the first verification identifier (setting_version) is used to identify the pushed block data. If the first verification identifier matches the first version identifier, the computer device determines that the block data carried in the first push data is the block data of the block to be synchronized.

[0148] S305: When it is detected that the remaining capacity of the block cache space is less than the capacity threshold, an occupancy notification is sent to the push node.

[0149] The occupancy notification is used to instruct the push node to suspend pushing the block data of the block that the computer device needs to synchronize. Optionally, the occupancy notification may also carry time indication information, and the time indication information is used to indicate the duration of suspending the push.

[0150] S306: In response to the notification condition being triggered, a capacity notification is generated based on the current remaining capacity of the block cache space, and the capacity notification is sent to the push node.

[0151] The capacity notification is used to notify the push node computer device of the current remaining capacity of the block cache space. The notification conditions include any of the following: the current time matches the preset time (such as the computer device periodically sends a capacity notification to the push node), and the change amount of the block cache space is detected to be greater than the change amount threshold; wherein the change amount is used to indicate the difference between the current remaining capacity of the block cache space and the remaining capacity of the block cache space at the target time (such as the time when the capacity notification was last sent to the push node).

[0152] For example, when the computer device detects that the remaining capacity of the block cache space is less than 10% of the total capacity, an occupancy notification is sent to the push node. After receiving the occupancy notification, the push node suspends pushing block data to the computer device. When the computer device detects that the remaining capacity of the block cache space is greater than 50% of the total capacity, a capacity notification is sent to the push node. After receiving the capacity notification, the push node continues (based on the capacity notification) to push block data to the computer device (such as sending third push data to the computer device).

[0153] S307: Obtain the third push data returned by the push node.

[0154] The amount of block data carried by the third push data is determined by the push node based on the capacity notification; that is, by sending the capacity notification to the push node, the push amount of block data can be dynamically adjusted, making the block data push more flexible and reducing the block data loss caused by insufficient block cache space.

[0155] S308. When the end notification sent by the push node is obtained, the block synchronization is ended.

[0156] The end notification includes an end code, which is used to indicate whether this push ends normally. If the end code is a valid value, the computer device determines that the push node has completed the push of the required synchronized blocks (that is, this push ends normally); correspondingly, if the end code is an invalid value, the computer device determines that the push node pushes abnormally.

[0157] In an embodiment of the present application, when it is detected that the local blockchain copy meets the block synchronization condition, a negotiation request is sent to the push node, and the first response information returned by the push node is obtained. If the negotiation result indicates that the push node agrees to push the block to be synchronized, the first configuration information is generated, and the first push data is obtained from the push node through the first configuration information. The first push data carries the block data of the block to be synchronized. It can be seen that before requesting the synchronization block, the block to be synchronized is negotiated with the push node through the negotiation request, which can reduce invalid requests caused by information asymmetry, thereby improving the efficiency of block synchronization. In addition, during the negotiation process, the push node of the synchronization block can be flexibly selected according to the push workload being processed by the push node, further improving the efficiency of block synchronization. By sending a capacity notification to the push node, the push amount of block data can be dynamically adjusted, making the block data push more flexible and reducing the loss of block data due to insufficient block cache space.

[0158] See also Figure 5 , Figure 5 A flowchart of another block synchronization method provided in an embodiment of the present application, the block synchronization method can be executed by a computer device; for example, Figure 1d The push node 102 shown in FIG. Figure 5 As shown, the block synchronization method may include the following steps S501 to S504:

[0159] S501: Acquire a negotiation request sent by a synchronization node.

[0160] The negotiation request includes block indication information, and the block indication information is used to indicate the blocks that the synchronization node needs to synchronize.

[0161] S502: Detect whether the block indicated by the block indication information exists in the local blockchain copy, and return a first response message to the synchronization node based on the detection result.

[0162] The first response information includes the negotiation result corresponding to the negotiation request. In the specific implementation process, the negotiation result corresponding to the negotiation request can be indicated by plain text or cipher text, or by a response code.

[0163] In one embodiment, the negotiation result corresponding to the negotiation request can be indicated by a response code. Specifically, the computer device detects whether there is a block indicated by the block indication information in the local blockchain copy. If the block indicated by the block indication information exists in the local blockchain copy, the computer device can further determine whether there is a restriction (such as data hiding, or data range restriction, etc.) on the block indicated by the block indication information. If the block indicated by the block indication information exists in the local blockchain copy, and there is no restriction on the block indicated by the block indication information, and the computer device agrees to push (such as the current state of the computer device is in an idle state) the block required by the synchronization node (indicated by the block data), the computer device sets the response code to a valid value and generates a first response message based on the response code; otherwise (such as the computer device does not agree to push the block required by the synchronization node, the block indicated by the block indication information has (pushing) restrictions, etc.), the computer device sets the response code to an invalid value and generates a first response message based on the response code. After generating the first response message, the computer device returns the first response message to the synchronization node.

[0164] S503: If it is agreed to push the blocks required for synchronization to the synchronization node, the first configuration information sent by the synchronization node is obtained.

[0165] The first configuration information includes capacity information, and the capacity information is used to indicate the capacity of the block cache space. In one embodiment, if the computer device agrees to push the blocks required for synchronization to the synchronization node, the first configuration information sent by the synchronization node is obtained. In another embodiment, if the computer device does not agree to push the blocks required for synchronization to the synchronization node, the negotiation is terminated (if the synchronization device sends the first configuration information, the first configuration information is not received).

[0166] S504: Generate first push data using the first configuration information and the blocks to be synchronized, and send the first push data to the synchronization node.

[0167] The first push data carries the block data of the block that the synchronization node needs to synchronize, and the amount of the block data is determined based on the capacity information in the first configuration information. The first push data may also include a block height, which is used to indicate the starting height of the block carried in the first push data.

[0168] In one embodiment, the first configuration information includes capacity information, and the computer device determines the amount of the pushed block data according to the capacity information; for example, assuming that the capacity information indicates that the block cache space of the synchronization node can still accommodate 10 block data, the computer device can determine the amount of the pushed block data to be between 1 and 10. After determining the amount of the pushed block data, the computer device packages the block data to obtain the first pushed data.

[0169] In another embodiment, the first configuration information includes capacity information and a first version identifier, and the first version identifier is used to identify the block that the synchronization node needs to synchronize (i.e., the block indicated by the block indication information). After the computer device determines the data volume of the pushed block data according to the capacity information, it establishes an association relationship between the pushed block data and the first version identifier to obtain a first verification identifier of the block data; for example, the first version identifier is used as the first verification identifier of the pushed block data, or the first verification identifier of the pushed block data is generated based on the first version identifier. After obtaining the first verification identifier of the block data, the pushed block data and the first verification identifier are packaged to obtain the first pushed data.

[0170] In addition, the first configuration information may also include a configuration list, which is used to indicate relevant configurations in the block push process (such as the format of the block data, sharding configuration, encryption method, etc.). The configuration list may include one or more configuration items, and each configuration item may be stored in the form of a "key-value pair". The computer device may configure the block data based on the configuration list.

[0171] After generating the first push data, the computer device sends the first push data to the synchronization node. It should be noted that when the number of pushed block data is multiple, the computer device can push one by one (i.e., push one block data each time), partially push (i.e., push multiple block data each time), or push all (i.e., push the block data within the capacity of the synchronization node block cache space at one time), and this application does not limit this.

[0172] In the embodiment of the present application, the negotiation request sent by the synchronization node is obtained, and the block indicated by the block indication information is detected in the local blockchain copy, and the first response information is returned to the synchronization node based on the detection result. If it is agreed to push the block to be synchronized to the synchronization node, the first configuration information sent by the synchronization node is obtained, and the first push data is generated through the first configuration information and the block to be synchronized, and the first push data is sent to the synchronization node. The first push data carries the block data of the block to be synchronized. It can be seen that before pushing the block, the first response information is used to inform the synchronization node whether it agrees to push the block to be synchronized, which can reduce invalid requests caused by information asymmetry, thereby improving the efficiency of block synchronization.

[0173] See also Figure 6 , Figure 6 A flowchart of another block synchronization method provided in an embodiment of the present application, the block synchronization method can be executed by a computer device; for example, Figure 1d The push node 102 shown in FIG. Figure 6 As shown, the block synchronization method may include the following steps S601 to S611:

[0174] S601: Acquire a negotiation request sent by a synchronization node.

[0175] The negotiation request includes block indication information, and the block indication information is used to indicate the blocks that the synchronization node needs to synchronize.

[0176] In one embodiment, the block indication information includes the starting height of the block and the number of blocks. If the number of blocks is an invalid value (such as 0), when it is detected that there is an updated block in the local blockchain copy, the computer device sends a fourth push data to the synchronization node, and the fourth push data carries the block data of the updated block. In other words, when the number of blocks is an invalid value or a preset value, it means that there is no upper limit for this block data synchronization. Whenever there is an updated block in the local blockchain copy of the push node, the block data of the updated block is pushed to the synchronization node. Until the push node or the synchronization node sends an end notification to the other party, the block push ends; for example, when the end notification sent by the synchronization node is obtained, the computer device stops pushing blocks to the synchronization node.

[0177] It can be seen that by indicating the block data to be pushed through the block indication information in the negotiation request, compared with requesting block data in batches, the number of times the synchronization request is sent can be reduced, unnecessary waste of resources can be reduced, and the efficiency of block synchronization can be further improved. It should be noted that through the above implementation method, it is also possible to prevent the original push process from degenerating into a pull request when the difference between the height of the block in the synchronization node and the height of the block in the push node is shortened to 1. Compared with push, a pull request requires a complete summation and reception message transmission to obtain a piece of data, which will increase the amount of message transmission and waiting time during the data reception process, while push can compress the number of message transmissions as much as possible to improve the synchronization efficiency of block data.

[0178] S602: Detect whether the block indicated by the block indication information exists in the local blockchain copy, and return a first response message to the synchronization node based on the detection result.

[0179] In one embodiment, if the computer device agrees to push the required synchronized blocks to the synchronization node, the computer device can also generate load information based on the current (block) push workload, add the load information to the first response information, and return the first response information to the synchronization node.

[0180] S603: If it is agreed to push the blocks required for synchronization to the synchronization node, the first configuration information sent by the synchronization node is obtained.

[0181] S604: Generate first push data using the first configuration information and the blocks to be synchronized, and send the first push data to the synchronization node.

[0182] For the specific implementation of step S603 and step S604, please refer to Figure 5 The implementation of steps S502 to S504 will not be repeated here.

[0183] S605: Obtain second configuration information sent by the synchronization node.

[0184] The second configuration information includes a second version identifier and a height interval, and the second version identifier is used to identify the block indicated by the height interval.

[0185] In one embodiment, the second configuration information is sent by the synchronization node to the computer device when another push node refuses (is unable to) push the required block data (such as belonging to a shard interval). The second configuration information is used to update the block data that needs to be synchronized from the computer device; for example, the synchronization node plans to synchronize the blocks belonging to shard interval 1 (such as height interval 1) from push node 1, and synchronize the blocks belonging to shard interval 2 (such as height interval 2) from push node 2. When the synchronization node detects that push node 2 cannot push the block data of the blocks belonging to shard interval 2 (such as height interval 2), the synchronization node sends the second configuration information to push node 1, and the second configuration information requests synchronization of the block data of the blocks belonging to shard interval 1 and (part of) the blocks belonging to shard interval 2 from push node 1.

[0186] It is understandable that, if upon receiving the second configuration information, the computer device agrees to push the block indicated by the height interval in the second configuration information to the synchronization node, and the push of the block data indicated by the first configuration information has not been completed, then the push of the block data indicated by the first configuration information is stopped, and step S606 is continued.

[0187] S606: If it is agreed to push the block indicated by the height interval to the synchronization node, a third response message is generated based on the second version identifier.

[0188] The third response information includes a second verification identifier, where the second verification identifier is used to identify the block carried in the second pushed data.

[0189] In one embodiment, the computer device establishes an association relationship between the pushed block data (i.e., the block data used to generate the second pushed data) and the second version identifier, and obtains a second verification identifier of the block data; for example, the second version identifier is used as the second verification identifier of the pushed block data, or the second verification identifier of the pushed block data is generated based on the second version identifier. After obtaining the second verification identifier of the block data, the computer device generates third response data based on the second verification identifier of the block data.

[0190] S607: Generate second push data based on the block indicated by the height interval, and send the second push data and third response information to the synchronization node.

[0191] The computer device determines the blocks that the synchronization node needs to synchronize according to the height interval, and generates the second push data based on the block data of the blocks that the synchronization node needs to synchronize. It can be understood that the amount of block data carried by the second push data is less than the remaining capacity of the current block cache space of the synchronization node.

[0192] Further, the computer device sends second push data and third response information to the synchronization node.

[0193] S608: When the occupancy notification sent by the synchronization node is obtained, the pushing of the blocks required for synchronization to the synchronization node is stopped.

[0194] In one embodiment, the occupancy notification is used to indicate that the remaining capacity of the current block cache space of the synchronization node is less than the capacity threshold, and the computer device suspends pushing the block data of the blocks to be synchronized to the synchronization node to avoid the loss of the pushed block data (invalid push).

[0195] S609: Obtain the capacity notification sent by the synchronization node.

[0196] The capacity notification is generated by the synchronization node based on the current remaining capacity of the block cache space. In one embodiment, after obtaining the capacity notification, the computer device can determine the quantity threshold through the current remaining capacity of the block cache space of the synchronization node indicated by the capacity notification, and the quantity threshold is used to limit the amount of block data pushed to the synchronization node.

[0197] S610: Generate third push data based on the capacity notification, and send the third push data to the synchronization node.

[0198] In one embodiment, the computer device packages the block data of the blocks that the synchronization node needs to synchronize based on the quantity threshold to obtain the third push data, and the amount of block data carried by the third push data is less than the quantity threshold. After obtaining the third push data, the computer device sends the third push data to the synchronization node.

[0199] It can be seen that by interacting with the remaining capacity of the block cache space of the synchronization node during the push process, the push speed of the block data can be controlled, and the block data can be pushed continuously, and the synchronization node does not need to make multiple requests in batches.

[0200] S611. Send an end notification to the synchronization node.

[0201] In one embodiment, if the block push required by the synchronization node is completed, the computer device sends an end notification to the synchronization node, and the end notification includes an end code, and the end code is a valid value (used to indicate that the push is completed normally).

[0202] In another embodiment, if the block push required by the synchronization node is abnormal, the computer device sends an end notification to the synchronization node, and the end notification includes an end code, and the end code is an invalid value (used to indicate a push abnormality).

[0203] Figure 7 A block synchronization architecture diagram provided in an embodiment of the present application. Figure 7 As shown, the block synchronization process is as follows:

[0204] (1) The sync node initiates a negotiation request to the push node, along with the requested block height and block number. If the block number is an invalid value (such as 0), it means that there is no limit on the number of blocks to be pushed, and the push node can keep pushing. Every new block added to the local blockchain copy of the push node is pushed to the sync node until either party initiates a push end notification.

[0205] (2) After receiving the negotiation request, the push node verifies whether the local blockchain copy contains the block data of the block requested to be synchronized by the synchronization node. If there are restrictions on the block data in the local blockchain copy, it is necessary to determine whether to agree to push the required synchronized block to the synchronization node based on the negotiation request. If it agrees to push the required synchronized block to the synchronization node, the push node returns the current load and response code through the first response information, and the response code is used to indicate that it agrees to push the required synchronized block to the synchronization node; accordingly, if it agrees to push the required synchronized block to the synchronization node, the push node returns the response code through the first response information, and the response code is used to indicate that it does not agree to push the required synchronized block to the synchronization node (i.e., the negotiation fails).

[0206] (3) If the negotiation fails, the block synchronization process is terminated. If the negotiation is successful, the synchronization node generates a first version number (which can be randomly generated / agreed generation method) and sends the first configuration information to the push node. The first configuration information includes the first version number. In addition, the first configuration information also carries the configuration necessary for block data push (such as capacity information). The meaning represented by the specific configuration item id can be agreed upon by yourself, and this application does not impose any restrictions on this. Setting the format of the configuration item to an array format can make it easier to expand the configuration, such as: in the implementation of multi-node sharding push, the configuration can carry relevant configuration items for the shards. Other things such as requiring other information to be included in the data can be expanded in the configuration item.

[0207] (4) After receiving the first configuration information, the push node returns a second response information, which is accompanied by a first verification identifier (the synchronization node can verify the response to the first configuration information based on the first verification identifier). The push node initializes the block data push process based on the first configuration information, and then pushes the block data required by the synchronization node.

[0208] (5) During the synchronization process, the synchronization node can adjust the capacity of the block cache space according to its own data processing progress and send a capacity notification to the push node.

[0209] (6) When the remaining capacity of the block cache space of the synchronization node is less than the capacity threshold (e.g., the block cache space is full), the push node suspends pushing block data until it determines based on a new capacity notification that the remaining capacity of the block cache space of the synchronization node meets the data push conditions, and then continues to push block data to the synchronization node.

[0210] (7) During the block data push process, if the synchronization node needs to adjust the push configuration (i.e., adjust the first configuration information), the second configuration information is sent to the push node, and the second configuration information carries the updated block height (used to indicate the block that needs to be synchronized) and the second version identifier (used to distinguish from the block data in the first configuration information). For example, in the scenario of multi-node shard push, if a push node is unavailable (push fails), the synchronization node can adjust the push configuration of other push nodes to complete the synchronization of block data.

[0211] (8) After receiving the second configuration information, the push node returns a third response message, which carries a second verification identifier (the synchronization node can verify the response to the second configuration information based on the second verification identifier), and then updates the push process of the block data based on the second configuration information, and then pushes the block data required by the synchronization node.

[0212] (9) When negotiating a request, if the number of blocks attached is a positive number n, the push node sends a push completion notification after pushing n blocks. The completion notification includes an end code (code). If the end code is a valid value, it indicates that the push of the blocks that the synchronization node needs to synchronize is complete; if the end code is an invalid value, it indicates that the push of the blocks that the synchronization node needs to synchronize is abnormal. For different push exceptions, the two parties can agree on different error codes to assist in determining the cause of the push exception.

[0213] Depend on Figure 7 It can be seen that the block synchronization method provided by the present application realizes a complete protocol process including a negotiation phase, a push phase, and an end phase. The block synchronization method adds a negotiation mechanism to solve the problem of low block synchronization efficiency caused by information asymmetry between synchronization nodes and push nodes. At the same time, the negotiation mechanism gives the blockchain more implementation mechanisms and functional extensions, and does not affect the push process of block data. In addition, the block synchronization method provided by the present application is a complete process. During the block synchronization process, it is not necessary to interrupt the processing every time, and it avoids the change from push to pull process when the height difference of the blockchain in the synchronization node and the push node is small. Again, this method has good scalability and flexibility in use. Whether it is the change in push mode, the expansion of push data, etc., it can be implemented based on the expansion of configuration items without changing the entire process. At the same time, for different implementations, such as the block synchronization process requires multi-node sharding, or the need for data security verification during the synchronization process, etc., they can be expanded and implemented in the synchronization method provided by the present application.

[0214] In the embodiment of the present application, the negotiation request sent by the synchronization node is obtained, and the block indicated by the block indication information is detected in the local blockchain copy, and the first response information is returned to the synchronization node based on the detection result. If it is agreed to push the required synchronized block to the synchronization node, the first configuration information sent by the synchronization node is obtained, and the first push data is generated by the first configuration information and the required synchronized block, and the first push data is sent to the synchronization node. The first push data carries the block data of the required synchronized block. It can be seen that before pushing the block, the first response information is used to inform the synchronization node whether it agrees to push the required synchronized block, which can reduce invalid requests caused by information asymmetry, thereby improving the efficiency of block synchronization. In addition, by interacting with the remaining capacity of the block cache space of the synchronization node during the push process, the push speed of the block data can be controlled, and the block data can be pushed continuously, and the synchronization node does not need to request multiple times in batches. The block indication information in the negotiation request indicates the block data to be pushed. Compared with requesting block data in batches, the number of times the synchronization request is sent can be reduced, unnecessary resource waste can be reduced, and the efficiency of block synchronization can be further improved.

[0215] The method of the embodiment of the present application is described in detail above. In order to facilitate better implementation of the above scheme of the embodiment of the present application, the device of the embodiment of the present application is provided below accordingly.

[0216] See also Figure 8 , Figure 8 A schematic diagram of the structure of a block synchronization device provided in an embodiment of the present application is shown in FIG. Figure 8 The block synchronization apparatus shown may be mounted in a computer device, which may specifically be a terminal device or a server. Figure 8 The block synchronization device shown can be used to perform the above Figure 2 and Figure 3 Some or all of the functions of the described method embodiments. Figure 8 , the block synchronization device comprises:

[0217] The sending unit 801 is used to send a negotiation request to the push node when it is detected that the local blockchain copy meets the block synchronization condition, where the negotiation request includes block indication information, where the block indication information is used to indicate the block to be synchronized, and the block synchronization condition includes: the height of the local blockchain copy is lower than the height threshold;

[0218] An acquiring unit 802 is configured to acquire first response information returned by the push node, where the first response information includes a negotiation result corresponding to the negotiation request;

[0219] The processing unit 803 is configured to generate first configuration information if the negotiation result indicates that the push node agrees to push the blocks to be synchronized, where the first configuration information includes capacity information, and the capacity information is used to indicate the capacity of the block cache space;

[0220] The acquisition unit 802 is further used to acquire first push data from the push node through the first configuration information, where the first push data carries block data of the blocks to be synchronized, and the data volume of the block data is determined by the push node based on the capacity information.

[0221] In one implementation, the first configuration information further includes a first version identifier, and the first version identifier is used to identify the block indicated by the block indication information; the processing unit 803 is used to obtain the first push data from the push node through the first configuration information, specifically for:

[0222] Sending first configuration information to the push node;

[0223] Obtaining second response information and the first pushed data returned by the push node, where the second response information includes a first verification identifier, and the first verification identifier is used to identify the block carried in the first pushed data;

[0224] If the first verification identifier matches the first version identifier, it is determined that the block data carried in the first pushed data is the block data of the block to be synchronized.

[0225] In one embodiment, the processing unit 803 is used to send a negotiation request to the push node when it is detected that the local blockchain copy meets the block synchronization condition, specifically for:

[0226] When it is detected that the local blockchain copy meets the block synchronization conditions, the blocks to be synchronized are sharded to obtain N height intervals, which do not overlap with each other, and N is an integer greater than 1;

[0227] Generate M negotiation requests based on the N height intervals, the block indication information in each negotiation request is used to indicate at least one of the N height intervals, and M is an integer greater than 1 and less than or equal to N;

[0228] Send M negotiation requests to M push nodes.

[0229] In one implementation, the M push nodes include a first push node and a second push node, and if the block in the first height interval is not successfully synchronized from the second push node, the processing unit 803 is further configured to:

[0230] Sending second configuration information to the first push node; the second configuration information includes a second version identifier and a second height interval; the first height interval is included in the second height interval, and the second version identifier is used to identify the block indicated by the second height interval;

[0231] Obtaining third response information and second pushed data returned by the first push node, where the third response information includes a second verification identifier, and the second verification identifier is used to identify a block carried in the second pushed data;

[0232] If the second verification identifier matches the second version identifier, it is determined that the block carried in the second pushed data is the block indicated by the second height interval;

[0233] The local blockchain copy is updated according to the second pushed data to obtain an updated local blockchain copy.

[0234] In one implementation, the processing unit 803 is further configured to:

[0235] When it is detected that the remaining capacity of the block cache space is less than the capacity threshold, an occupancy notification is sent to the push node, and the occupancy notification is used to instruct the push node to suspend pushing the blocks that need to be synchronized.

[0236] In one implementation, the processing unit 803 is further configured to:

[0237] In response to a notification condition being triggered, generating a capacity notification based on the current remaining capacity of the block cache space, the notification condition including any one of the following: the current moment matches the preset moment, and the change amount of the block cache space is detected to be greater than the change amount threshold; the change amount is used to indicate the difference between the current remaining capacity of the block cache space and the remaining capacity of the block cache space at the target moment;

[0238] Send capacity notification to push nodes;

[0239] The third push data returned by the push node is obtained, and the data volume of the block data carried by the third push data is determined by the push node based on the capacity notification.

[0240] In one implementation, the first response information further includes load information, where the load information is used to indicate the current push workload of the push node; if the negotiation result indicates that the push node agrees to push the blocks to be synchronized, the processing unit 803 is used to generate first configuration information, specifically for:

[0241] If the load information indicates that the current push workload of the push node is less than the workload threshold, the first configuration information is generated.

[0242] In one implementation, the processing unit 803 is further configured to:

[0243] When the end notification sent by the push node is obtained, the block synchronization ends, and the end notification includes the end code;

[0244] If the end code is a valid value, it is determined that the push node has completed the push of the required synchronized blocks;

[0245] If the end code is an invalid value, it is determined that the push node push is abnormal.

[0246] According to one embodiment of the present application, Figure 2 and Figure 3 Some of the steps involved in the block synchronization method shown can be represented by Figure 8 The block synchronization device shown is executed by each unit. For example, Figure 2 The step S201 shown in FIG. 1 can be performed by Figure 8 The sending unit 801 shown in FIG. 8 is executed, and step S202 and step S204 can be performed by Figure 8 The acquisition unit 802 shown in FIG. 8 is executed, and step S203 can be performed by Figure 8 The processing unit 803 shown executes; Figure 3 Step S301, step S305 and step S306 shown in FIG. Figure 8 The sending unit 801 shown in FIG. 8 is executed, and steps S302, S304, S307 and S308 can be performed by Figure 8 The acquisition unit 802 shown in FIG. 1 is executed, and step S303 can be performed by Figure 8 The processing unit 803 is shown to execute. Figure 8 The various units in the block synchronization device shown can be separately or completely combined into one or several other units to form, or one (some) of the units can be further divided into multiple functionally smaller units to form, which can achieve the same operation without affecting the realization of the technical effects of the embodiments of the present application. The above-mentioned units are divided based on logical functions. In actual applications, the functions of one unit can also be implemented by multiple units, or the functions of multiple units can be implemented by one unit. In other embodiments of the present application, the block synchronization device may also include other units. In actual applications, these functions can also be implemented with the assistance of other units, and can be implemented by the collaboration of multiple units.

[0247] According to another embodiment of the present application, the program can be executed by running a program on a general computing device such as a computer device including a central processing unit (CPU), a random access memory medium (RAM), a read-only memory medium (ROM), and other processing elements and storage elements. Figure 2 and Figure 3 A computer program (including program code) for each step involved in the corresponding method shown in Figure 8 The block synchronization device shown in and the block synchronization method of the embodiment of the present application are implemented. The computer program can be recorded on, for example, a computer readable recording medium, and loaded into the above-mentioned computing device through the computer readable recording medium and run therein.

[0248] Based on the same inventive concept, the principles and beneficial effects of solving the problems by the block synchronization device provided in the embodiment of the present application are similar to the principles and beneficial effects of solving the problems by the block synchronization method in the method embodiment of the present application. Please refer to the principles and beneficial effects of the implementation of the method. For the sake of concise description, they will not be repeated here.

[0249] See also Fig. 9 , Fig. 9 A schematic diagram of the structure of another block synchronization device provided in an embodiment of the present application, Fig. 9 The block synchronization apparatus shown may be mounted in a computer device, which may specifically be a terminal device or a server. Fig. 9 The block synchronization device shown can be used to perform the above Figure 5 and Figure 6 Some or all of the functions of the described method embodiments. Fig. 9 , the block synchronization device comprises:

[0250] An acquiring unit 901 is configured to acquire a negotiation request sent by a synchronization node, where the negotiation request includes block indication information, and the block indication information is used to indicate a block to be synchronized;

[0251] The processing unit 902 is used to detect whether the block indicated by the block indication information exists in the local blockchain copy, and return first response information to the synchronization node based on the detection result, where the first response information includes a negotiation result corresponding to the negotiation request;

[0252] The acquisition unit 901 is further configured to acquire first configuration information sent by the synchronization node if it is agreed to push the required synchronized blocks to the synchronization node, the first configuration information including capacity information, and the capacity information is used to indicate the capacity of the block cache space;

[0253] The processing unit 902 is also used to generate first push data through the first configuration information and the blocks to be synchronized, and send the first push data to the synchronization node. The first push data carries the block data of the blocks to be synchronized, and the data volume of the block data is determined based on the capacity information.

[0254] In one implementation, the first configuration information further includes a first version identifier, and the first version identifier is used to identify the block indicated by the block indication information; the processing unit 902 is further used to:

[0255] Generate a second response message based on the first version identifier, where the second response message includes a first verification identifier, where the first verification identifier is used to identify a block carried in the first pushed data;

[0256] Sending second response information to the synchronization node.

[0257] In one implementation, the processing unit 902 is further configured to:

[0258] Obtain second configuration information sent by the synchronization node, where the second configuration information includes a second version identifier and a height interval, where the second version identifier is used to identify the block indicated by the height interval;

[0259] If it is agreed to push the block indicated by the height interval to the synchronization node, a third response message is generated based on the second version identifier, and the third response message includes a second verification identifier, and the second verification identifier is used to identify the block carried in the second pushed data;

[0260] Generate second push data based on the block indicated by the height interval, and send the second push data and third response information to the synchronization node.

[0261] In one implementation, the processing unit 902 is further configured to:

[0262] When receiving the occupancy notification sent by the synchronization node, suspend pushing the blocks that need to be synchronized to the synchronization node.

[0263] In one implementation, the processing unit 902 is further configured to:

[0264] Get the capacity notification sent by the synchronization node. The capacity notification is generated by the synchronization node based on the current remaining capacity of the block cache space;

[0265] Determine the quantity threshold by synchronizing the current remaining capacity of the node's block cache space;

[0266] The block data of the blocks that the synchronization node needs to synchronize are packaged based on the quantity threshold to obtain third pushed data, where the amount of block data carried by the third pushed data is less than the quantity threshold;

[0267] The third push data is sent to the synchronization node.

[0268] In one implementation, the processing unit 902 is further configured to:

[0269] If the block push required by the synchronization node is completed, an end notification is sent to the synchronization node. The end notification includes an end code, which is a valid value.

[0270] If the block push required by the synchronization node is abnormal, an end notification is sent to the synchronization node. The end notification includes an end code, and the end code is an invalid value.

[0271] In one implementation, the block indication information includes the block starting height and the number of blocks; the processing unit 902 is further configured to:

[0272] If the number of blocks is an invalid value, when it is detected that there is an updated block in the local blockchain copy, fourth push data is sent to the synchronization node, and the fourth push data carries the block data of the updated block;

[0273] When the end notification sent by the synchronization node is obtained, stop pushing blocks to the synchronization node.

[0274] According to one embodiment of the present application, Figure 5 and Figure 6 Some of the steps involved in the block synchronization method shown can be represented by Fig. 9 The block synchronization device shown is executed by each unit. For example, Figure 5 Steps S501 and S503 shown in FIG. 5 can be obtained by Fig. 9 The acquisition unit 901 shown in FIG. 1 is executed, and step S502 and step S504 can be performed by Fig. 9 The processing unit 902 shown executes; Figure 6 Steps S601, S603, S605 and S609 shown in FIG. 1 can be obtained by Fig. 9 The acquisition unit 901 shown in FIG. 1 is executed, and steps S602, S604, S606 to S608, S610 and S611 can be performed by Fig. 9 Processing unit 902 is shown executing. Fig. 9The various units in the block synchronization device shown can be separately or completely combined into one or several other units to form, or one (some) of the units can be further divided into multiple functionally smaller units to form, which can achieve the same operation without affecting the realization of the technical effects of the embodiments of the present application. The above-mentioned units are divided based on logical functions. In actual applications, the functions of one unit can also be implemented by multiple units, or the functions of multiple units can be implemented by one unit. In other embodiments of the present application, the block synchronization device may also include other units. In actual applications, these functions can also be implemented with the assistance of other units, and can be implemented by the collaboration of multiple units.

[0275] According to another embodiment of the present application, the program can be executed by running a program on a general computing device such as a computer device including a central processing unit (CPU), a random access memory medium (RAM), a read-only memory medium (ROM), and other processing elements and storage elements. Figure 5 and Figure 6 A computer program (including program code) for each step involved in the corresponding method shown in Fig. 9 The block synchronization device shown in and the block synchronization method of the embodiment of the present application are implemented. The computer program can be recorded on, for example, a computer readable recording medium, and loaded into the above-mentioned computing device through the computer readable recording medium and run therein.

[0276] Based on the same inventive concept, the principles and beneficial effects of solving the problems by the block synchronization device provided in the embodiment of the present application are similar to the principles and beneficial effects of solving the problems by the block synchronization method in the method embodiment of the present application. Please refer to the principles and beneficial effects of the implementation of the method. For the sake of concise description, they will not be repeated here.

[0277] See also Fig.10 , Fig.10 The following is a schematic diagram of the structure of a computer device provided in an embodiment of the present application. The computer device may be a terminal device or a server. Fig.10As shown, the computer device at least includes a processor 1001, a communication interface 1002 and a memory 1003. The processor 1001, the communication interface 1002 and the memory 1003 can be connected via a bus or other means. The processor 1001 (or central processing unit (CPU)) is the computing core and control core of the computer device, which can parse various instructions in the computer device and process various data of the computer device. For example, the CPU can be used to parse the power on and off instructions issued by the object to the computer device, and control the computer device to perform power on and off operations; for example, the CPU can transmit various interactive data between the internal structures of the computer device, and so on. The communication interface 1002 can optionally include a standard wired interface, a wireless interface (such as WI-FI, a mobile communication interface, etc.), which can be used to send and receive data under the control of the processor 1001; the communication interface 1002 can also be used for the transmission and interaction of data within the computer device. The memory 1003 (Memory) is a memory device in the computer device, which is used to store programs and data. It is understandable that the memory 1003 here may include a built-in memory of the computer device, and of course may also include an extended memory supported by the computer device. The memory 1003 provides a storage space, which stores the operating system of the computer device, including but not limited to: Android system, iOS system, Windows Phone system, etc., which is not limited in this application.

[0278] The embodiment of the present application also provides a computer-readable storage medium (Memory), which is a memory device in a computer device for storing programs and data. It is understandable that the computer-readable storage medium here can include both built-in storage media in the computer device and, of course, extended storage media supported by the computer device. The computer-readable storage medium provides a storage space that stores the processing system of the computer device. In addition, a computer program suitable for being loaded and executed by the processor 1001 is also stored in the storage space. It should be noted that the computer-readable storage medium here can be a high-speed RAM memory, or a non-volatile memory, such as at least one disk storage; optionally, it can also be at least one computer-readable storage medium located away from the aforementioned processor.

[0279] In one embodiment, the processor 1001 performs the following operations by running the computer program in the memory 1003:

[0280] When it is detected that the local blockchain copy meets the block synchronization condition, a negotiation request is sent to the push node, the negotiation request includes block indication information, the block indication information is used to indicate the block to be synchronized, and the block synchronization condition includes: the height of the local blockchain copy is lower than the height threshold;

[0281] Obtaining first response information returned by the push node, where the first response information includes a negotiation result corresponding to the negotiation request;

[0282] If the negotiation result indicates that the push node agrees to push the blocks that need to be synchronized, first configuration information is generated, where the first configuration information includes capacity information, and the capacity information is used to indicate the capacity of the block cache space;

[0283] The first push data is obtained from the push node through the first configuration information. The first push data carries the block data of the block to be synchronized. The data volume of the block data is determined by the push node based on the capacity information.

[0284] As an optional embodiment, the first configuration information further includes a first version identifier, and the first version identifier is used to identify the block indicated by the block indication information; a specific embodiment in which the processor 1001 obtains the first push data from the push node through the first configuration information is:

[0285] Sending first configuration information to the push node;

[0286] Obtaining second response information and the first pushed data returned by the push node, where the second response information includes a first verification identifier, and the first verification identifier is used to identify the block carried in the first pushed data;

[0287] If the first verification identifier matches the first version identifier, it is determined that the block data carried in the first pushed data is the block data of the block to be synchronized.

[0288] As an optional embodiment, when the processor 1001 detects that the local blockchain copy meets the block synchronization condition, a specific embodiment of sending a negotiation request to the push node is:

[0289] When it is detected that the local blockchain copy meets the block synchronization conditions, the blocks to be synchronized are sharded to obtain N height intervals, which do not overlap with each other, and N is an integer greater than 1;

[0290] Generate M negotiation requests based on the N height intervals, the block indication information in each negotiation request is used to indicate at least one of the N height intervals, and M is an integer greater than 1 and less than or equal to N;

[0291] Send M negotiation requests to M push nodes.

[0292] As an optional embodiment, the M push nodes include a first push node and a second push node. If the block of the first height interval is not successfully synchronized from the second push node, the processor 1001 further performs the following operations by running the computer program in the memory 1003:

[0293] Sending second configuration information to the first push node; the second configuration information includes a second version identifier and a second height interval; the first height interval is included in the second height interval, and the second version identifier is used to identify the block indicated by the second height interval;

[0294] Obtaining third response information and second pushed data returned by the first push node, where the third response information includes a second verification identifier, and the second verification identifier is used to identify a block carried in the second pushed data;

[0295] If the second verification identifier matches the second version identifier, it is determined that the block carried in the second pushed data is the block indicated by the second height interval;

[0296] The local blockchain copy is updated according to the second pushed data to obtain an updated local blockchain copy.

[0297] As an optional embodiment, the processor 1001 further performs the following operations by running the computer program in the memory 1003:

[0298] When it is detected that the remaining capacity of the block cache space is less than the capacity threshold, an occupancy notification is sent to the push node, and the occupancy notification is used to instruct the push node to suspend pushing the blocks that need to be synchronized.

[0299] As an optional embodiment, the processor 1001 further performs the following operations by running the computer program in the memory 1003:

[0300] In response to a notification condition being triggered, generating a capacity notification based on the current remaining capacity of the block cache space, the notification condition including any one of the following: the current moment matches the preset moment, and the change amount of the block cache space is detected to be greater than the change amount threshold; the change amount is used to indicate the difference between the current remaining capacity of the block cache space and the remaining capacity of the block cache space at the target moment;

[0301] Send capacity notification to push nodes;

[0302] The third push data returned by the push node is obtained, and the data volume of the block data carried by the third push data is determined by the push node based on the capacity notification.

[0303] As an optional embodiment, the first response information further includes load information, and the load information is used to indicate the current push workload of the push node; if the negotiation result indicates that the push node agrees to push the blocks to be synchronized, the specific embodiment of the processor 1001 generating the first configuration information is:

[0304] If the load information indicates that the current push workload of the push node is less than the workload threshold, the first configuration information is generated.

[0305] As an optional embodiment, the processor 1001 further performs the following operations by running the computer program in the memory 1003:

[0306] When the end notification sent by the push node is obtained, the block synchronization ends, and the end notification includes the end code;

[0307] If the end code is a valid value, it is determined that the push node has completed the push of the required synchronized blocks;

[0308] If the end code is an invalid value, it is determined that the push node push is abnormal.

[0309] In another embodiment, the processor 1001 performs the following operations by running the computer program in the memory 1003:

[0310] Obtaining a negotiation request sent by a synchronization node, where the negotiation request includes block indication information, where the block indication information is used to indicate a block to be synchronized;

[0311] Detect whether the block indicated by the block indication information exists in the local blockchain copy, and return first response information to the synchronization node based on the detection result, where the first response information includes a negotiation result corresponding to the negotiation request;

[0312] If it is agreed to push the blocks to be synchronized to the synchronization node, first configuration information sent by the synchronization node is obtained, where the first configuration information includes capacity information, and the capacity information is used to indicate the capacity of the block cache space;

[0313] The first push data is generated by the first configuration information and the blocks to be synchronized, and the first push data is sent to the synchronization node. The first push data carries the block data of the blocks to be synchronized, and the data volume of the block data is determined based on the capacity information.

[0314] As an optional embodiment, the first configuration information further includes a first version identifier, and the first version identifier is used to identify the block indicated by the block indication information; the processor 1001 further performs the following operations by running the computer program in the memory 1003:

[0315] Generate a second response message based on the first version identifier, where the second response message includes a first verification identifier, where the first verification identifier is used to identify a block carried in the first pushed data;

[0316] Sending second response information to the synchronization node.

[0317] As an optional embodiment, the processor 1001 further performs the following operations by running the computer program in the memory 1003:

[0318] Obtain second configuration information sent by the synchronization node, where the second configuration information includes a second version identifier and a height interval, where the second version identifier is used to identify the block indicated by the height interval;

[0319] If it is agreed to push the block indicated by the height interval to the synchronization node, a third response message is generated based on the second version identifier, and the third response message includes a second verification identifier, and the second verification identifier is used to identify the block carried in the second pushed data;

[0320] Generate second push data based on the block indicated by the height interval, and send the second push data and third response information to the synchronization node.

[0321] As an optional embodiment, the processor 1001 further performs the following operations by running the computer program in the memory 1003:

[0322] When receiving the occupancy notification sent by the synchronization node, suspend pushing the blocks that need to be synchronized to the synchronization node.

[0323] As an optional embodiment, the processor 1001 further performs the following operations by running the computer program in the memory 1003:

[0324] Get the capacity notification sent by the synchronization node. The capacity notification is generated by the synchronization node based on the current remaining capacity of the block cache space;

[0325] Determine the quantity threshold by synchronizing the current remaining capacity of the node's block cache space;

[0326] The block data of the blocks that the synchronization node needs to synchronize are packaged based on the quantity threshold to obtain third pushed data, where the amount of block data carried by the third pushed data is less than the quantity threshold;

[0327] The third push data is sent to the synchronization node.

[0328] As an optional embodiment, the processor 1001 further performs the following operations by running the computer program in the memory 1003:

[0329] If the block push required by the synchronization node is completed, an end notification is sent to the synchronization node. The end notification includes an end code, which is a valid value.

[0330] If the block push required by the synchronization node is abnormal, an end notification is sent to the synchronization node. The end notification includes an end code, and the end code is an invalid value.

[0331] As an optional embodiment, the block indication information includes the block starting height and the number of blocks; the processor 1001 further performs the following operations by running the computer program in the memory 1003:

[0332] If the number of blocks is an invalid value, when it is detected that there is an updated block in the local blockchain copy, fourth push data is sent to the synchronization node, and the fourth push data carries the block data of the updated block;

[0333] When the end notification sent by the synchronization node is obtained, stop pushing blocks to the synchronization node.

[0334] Based on the same inventive concept, the principles and beneficial effects of solving the problems provided by the computer device in the embodiment of the present application are similar to the principles and beneficial effects of solving the problems provided by the block synchronization method in the method embodiment of the present application. Please refer to the principles and beneficial effects of the implementation of the method. For the sake of concise description, they will not be repeated here.

[0335] The embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. The computer program is suitable for being loaded by a processor and executing the block synchronization method of the above method embodiment.

[0336] The embodiment of the present application also provides a computer program product or a computer program, which includes a computer instruction stored in a computer-readable storage medium. The processor of the computer device reads the computer instruction from the computer-readable storage medium, and the processor executes the computer instruction, so that the computer device executes the above-mentioned block synchronization method.

[0337] The steps in the method of the embodiment of the present application can be adjusted in order, combined and deleted according to actual needs.

[0338] The modules in the device of the embodiment of the present application can be merged, divided and deleted according to actual needs.

[0339] In the embodiments of the present application, the "module" or "unit" involved refers to a computer program or a part of a computer program with a predetermined function, and works together with other related parts to achieve a predetermined goal, and can be implemented in whole or in part by using software, hardware (such as processing circuits or memories) or a combination thereof. Similarly, a processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be part of an overall module or unit that includes the function of the module or unit.

[0340] A person of ordinary skill in the art can understand that all or part of the steps in the various methods of the above embodiments can be completed by instructing related hardware through a program, and the program can be stored in a computer-readable storage medium, and the readable storage medium can include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0341] What is disclosed above is only a preferred embodiment of the present application, and it certainly cannot be used to limit the scope of rights of the present application. Ordinary technicians in this field can understand that all or part of the processes of implementing the above embodiment and equivalent changes made according to the claims of the present application are still within the scope covered by the application.

Claims

1. A blockchain synchronization method, characterized in that, the method includes: When it is detected that the local blockchain copy meets the blockchain synchronization condition, a negotiation request is sent to the push node, the negotiation request includes block indication information, and the block indication information is used to indicate the blocks to be synchronized. The blockchain synchronization condition includes: the height of the local blockchain copy is lower than the height threshold; Obtain the first response information returned by the push node, and the first response information includes the negotiation result corresponding to the negotiation request; If the negotiation result indicates that the push node agrees to push the blocks to be synchronized, generate first configuration information, and the first configuration information includes capacity information, and the capacity information is used to indicate the capacity of the block cache space; Obtain first push data from the push node through the first configuration information, and the first push data carries the block data of the blocks to be synchronized, and the data volume of the block data is determined by the push node based on the capacity information.

2. The method according to claim 1, characterized in that, the first configuration information further includes a first version identifier, and the first version identifier is used to identify the blocks indicated by the block indication information; the obtaining of the first push data from the push node through the first configuration information includes: Sending the first configuration information to the push node; Obtain the second response information and the first push data returned by the push node, and the second response information includes a first verification identifier, and the first verification identifier is used to identify the blocks carried in the first push data; If the first verification identifier matches the first version identifier, it is determined that the block data carried in the first push data is the block data of the blocks to be synchronized.

3. The method according to claim 1, characterized in that, the step of when it is detected that the local blockchain copy meets the blockchain synchronization condition and sending a negotiation request to the push node includes: When it is detected that the local blockchain copy meets the blockchain synchronization condition, perform sharding processing on the blocks to be synchronized to obtain N height intervals, and the N height intervals do not overlap with each other, and N is an integer greater than 1; Generate M negotiation requests based on the N height intervals, and the block indication information in each negotiation request is used to indicate at least one of the N height intervals, and M is an integer greater than 1 and less than or equal to N; Send the M negotiation requests to M push nodes.

4. The method according to claim 3, characterized in that, the M push nodes include a first push node and a second push node. If the blocks in the first height interval are not successfully synchronized from the second push node, the method further includes: Sending second configuration information to the first push node; the second configuration information includes a second version identifier and a second height interval; the first height interval is included in the second height interval, and the second version identifier is used to identify the blocks indicated by the second height interval; Obtain the third response information and the second push data returned by the first push node, and the third response information includes a second verification identifier, and the second verification identifier is used to identify the blocks carried in the second push data; If the second verification identifier matches the second version identifier, determining that the block carried in the second pushed data is the block indicated by the second height interval; The local blockchain copy is updated according to the second pushed data to obtain an updated local blockchain copy.

5. The method according to claim 1, It is characterized in that The method further comprises: When it is detected that the remaining capacity of the block cache space is less than the capacity threshold, an occupation notification is sent to the push node, where the occupation notification is used to instruct the push node to suspend pushing the blocks that need to be synchronized.

6. The method according to claim 1, It is characterized in that The method further comprises: In response to a notification condition being triggered, generating a capacity notification based on the current remaining capacity of the block cache space, the notification condition including any one of the following: the current moment matches the preset moment, a change amount of the block cache space is detected to be greater than a change amount threshold; the change amount is used to indicate the difference between the current remaining capacity of the block cache space and the remaining capacity of the block cache space at the target moment; Sending the capacity notification to the push node; The third push data returned by the push node is obtained, wherein the data volume of the block data carried by the third push data is determined by the push node based on the capacity notification.

7. The method according to claim 1, It is characterized in that The first response information also includes load information, where the load information is used to indicate the current push workload of the push node; If the negotiation result indicates that the pushing node agrees to push the blocks that need to be synchronized, then generating the first configuration information includes: If the load information indicates that the current push workload of the push node is less than the workload threshold, first configuration information is generated.

8. The method according to claim 1, It is characterized in that The method further comprises: When the end notification sent by the push node is obtained, the block synchronization is ended, and the end notification includes an end code; If the end code is a valid value, it is determined that the push node has completed the push of the blocks required for synchronization; If the end code is an invalid value, it is determined that the push of the push node is abnormal.

9. A block synchronization method, It is characterized in that The method comprises: Acquire a negotiation request sent by a synchronization node, wherein the negotiation request includes block indication information, and the block indication information is used to indicate a block to be synchronized; Detect whether the block indicated by the block indication information exists in the local blockchain copy, and return first response information to the synchronization node based on the detection result, where the first response information includes a negotiation result corresponding to the negotiation request; If it is agreed to push the blocks required for synchronization to the synchronization node, first configuration information sent by the synchronization node is obtained, where the first configuration information includes capacity information, and the capacity information is used to indicate the capacity of the block cache space; First push data is generated by using the first configuration information and the blocks to be synchronized, and the first push data is sent to the synchronization node. The first push data carries block data of the blocks to be synchronized, and the data volume of the block data is determined based on the capacity information.

10. The method according to claim 9, It is characterized in that The first configuration information further includes a first version identifier, and the first version identifier is used to identify the block indicated by the block indication information; the method further includes: Generate a second response message based on the first version identifier, where the second response message includes a first verification identifier, where the first verification identifier is used to identify a block carried in the first pushed data; The second response information is sent to the synchronization node.

11. The method according to claim 9, It is characterized in that The method further comprises: Acquire second configuration information sent by the synchronization node, where the second configuration information includes a second version identifier and a height interval, where the second version identifier is used to identify a block indicated by the height interval; If it is agreed to push the block indicated by the height interval to the synchronization node, a third response message is generated based on the second version identifier, and the third response message includes a second verification identifier, and the second verification identifier is used to identify the block carried in the second pushed data; Generate second push data based on the block indicated by the height interval, and send the second push data and the third response information to the synchronization node.

12. The method according to claim 9, It is characterized in that The method further comprises: When the occupancy notification sent by the synchronization node is obtained, the pushing of the blocks required for synchronization to the synchronization node is suspended.

13. The method of claim 9, It is characterized in that The method further comprises: Obtaining a capacity notification sent by the synchronization node, where the capacity notification is generated by the synchronization node based on a current remaining capacity of a block cache space; Determine the quantity threshold value according to the current remaining capacity of the block cache space of the synchronization node; Packing the block data of the blocks required to be synchronized by the synchronization node based on the quantity threshold to obtain third pushed data, wherein the amount of block data carried by the third pushed data is less than the quantity threshold; The third push data is sent to the synchronization node.

14. The method of claim 9, It is characterized in that The method further comprises: If the block push required by the synchronization node is completed, an end notification is sent to the synchronization node, and the end notification includes an end code, and the end code is a valid value; If the block push required by the synchronization node is abnormal, an end notification is sent to the synchronization node, and the end notification includes an end code, and the end code is an invalid value.

15. The method of claim 9, It is characterized in that The block indication information includes the block starting height and the number of blocks; the method further includes: If the number of blocks is an invalid value, when it is detected that an updated block exists in the local blockchain copy, fourth push data is sent to the synchronization node, where the fourth push data carries the block data of the updated block; When the end notification sent by the synchronization node is obtained, the block push to the synchronization node is stopped.

16. A block synchronization device, It is characterized in that The block synchronization device comprises: A sending unit, configured to send a negotiation request to a push node when it is detected that the local blockchain copy meets a block synchronization condition, wherein the negotiation request includes block indication information, and the block indication information is used to indicate a block to be synchronized, and the block synchronization condition includes: the height of the local blockchain copy is lower than a height threshold; an acquiring unit, configured to acquire first response information returned by the push node, wherein the first response information includes a negotiation result corresponding to the negotiation request; a processing unit, configured to generate first configuration information if the negotiation result indicates that the pushing node agrees to push the blocks to be synchronized, wherein the first configuration information includes capacity information, and the capacity information is used to indicate the capacity of the block cache space; The acquisition unit is further used to acquire first push data from the push node through the first configuration information, where the first push data carries block data of the blocks to be synchronized, and the data volume of the block data is determined by the push node based on the capacity information.

17. A block synchronization device, It is characterized in that The block synchronization device comprises: An acquiring unit, configured to acquire a negotiation request sent by a synchronization node, wherein the negotiation request includes block indication information, and the block indication information is used to indicate a block to be synchronized; a processing unit, configured to detect whether the block indicated by the block indication information exists in the local blockchain copy, and return first response information to the synchronization node based on the detection result, wherein the first response information includes a negotiation result corresponding to the negotiation request; The acquisition unit is further configured to acquire first configuration information sent by the synchronization node if it is agreed to push the blocks required for synchronization to the synchronization node, wherein the first configuration information includes capacity information, and the capacity information is used to indicate the capacity of the block cache space; The processing unit is also used to generate first push data through the first configuration information and the blocks to be synchronized, and send the first push data to the synchronization node, wherein the first push data carries the block data of the blocks to be synchronized, and the data volume of the block data is determined based on the capacity information.

18. A computer device, It is characterized in that include: a memory, wherein a computer program is stored in the memory; A processor, used to load the computer program to implement the block synchronization method as described in any one of claims 1-8; or used to load the computer program to implement the block synchronization method as described in any one of claims 9-15.

19. A computer-readable storage medium, It is characterized in that The computer-readable storage medium stores a computer program, and the computer program is suitable for being loaded by a processor and executing the block synchronization method as described in any one of claims 1-8; or is suitable for being loaded by a processor and executing the block synchronization method as described in any one of claims 9-15.

20. A computer program product, It is characterized in that The computer program product comprises a computer program, which is suitable for being loaded by a processor and executing the block synchronization method as described in any one of claims 1 to 8; or suitable for being loaded by a processor and executing the block synchronization method as described in any one of claims 9 to 15.

Images