Block chain node data synchronization method and device, storage medium and computer equipment

Abstract

The invention provides a block chain node data synchronization method and device, a storage medium and computer equipment. The method comprises the following steps: sending a block chain data synchronization request for a preset block chain network to a data sharing platform, and receiving first block height information returned by the data sharing platform; calculating a first block height range corresponding to the block data needing to be synchronized according to the state information of the locally stored block data and the first block height information; sending a block data downloading request to a data sharing platform based on the first block height range, and receiving target compressed block data corresponding to the first block height range returned by the data sharing platform; performing decompression on the target compressed block data, and performing data verification on the target block data obtained through decompression; and when the data verification result is qualified, synchronously updating the local block chain data based on the target block data. According to the method, the data synchronization efficiency of the block chain nodes in the block chain network can be improved.

Description

Technical Field

[0001] The present disclosure relates to the field of blockchain technology, and in particular to a blockchain node data synchronization method, device, storage medium and computer equipment. Background Art

[0002] Blockchain is a distributed ledger. Compared with traditional network data storage, blockchain has two core features: decentralization and data is difficult to tamper with. Based on these two features, the information recorded in blockchain is more authentic and reliable, which can solve the problem of mutual distrust between data processing objects.

[0003] The consensus mechanism is one of the core technologies of blockchain technology. The consensus mechanism completes the verification and confirmation of transactions in a relatively short period of time through the voting of special nodes (consensus nodes), so that the entire network can reach a consensus on the transaction. Since consensus nodes need to have the ability to verify transaction information, if a node in the blockchain wants to become a consensus node to participate in the consensus, it needs to have the block data of the entire chain. In this way, if a new node in the blockchain network wants to participate in the consensus, it needs to complete block synchronization.

[0004] In the related art, the block synchronization scheme for newly added nodes in the blockchain network synchronizes data block by block starting from the genesis block until the latest block height of the blockchain network is reached. This scheme requires newly added nodes to download a large amount of block data, resulting in very low block synchronization efficiency. Summary of the invention

[0005] The embodiments of the present disclosure provide a blockchain node data synchronization method, device, storage medium and computer equipment, which can improve the efficiency of data synchronization of newly added blockchain nodes.

[0006] According to one aspect of the present disclosure, a method for synchronizing blockchain node data is provided, the method being applied to a first node in a preset blockchain network that needs to synchronize blockchain data, the method comprising:

[0007] Sending a blockchain data synchronization request for the preset blockchain network to a data sharing platform, and receiving the first block height information returned by the data sharing platform, wherein the data sharing platform receives and stores a compressed block file exported in real time by a second node in the preset blockchain network, wherein the second node is a node that can participate in the consensus process of the preset blockchain network;

[0008] Calculating a first block height range corresponding to the block data to be synchronized according to the state information of the locally stored block data and the first block height information;

[0009] Sending a block data download request to the data sharing platform based on the first block height range, and receiving target compressed block data corresponding to the first block height range returned by the data sharing platform;

[0010] Decompressing the target compressed block data, and performing data verification on the decompressed target block data;

[0011] When the data verification result is qualified, the local blockchain data is synchronously updated based on the target block data.

[0012] According to one aspect of the present disclosure, a blockchain node data synchronization device is provided, the device being applied to a first node in a preset blockchain network that needs to perform blockchain data synchronization, the device comprising:

[0013] A first sending unit is used to send a blockchain data synchronization request for the preset blockchain network to a data sharing platform, and receive first block height information returned by the data sharing platform, wherein the data sharing platform receives and stores a compressed block file exported in real time by a second node in the preset blockchain network, wherein the second node is a node that can participate in the consensus process of the preset blockchain network;

[0014] A calculation unit, configured to calculate a first block height range corresponding to the block data to be synchronized according to the state information of the locally stored block data and the first block height information;

[0015] A second sending unit, configured to send a block data download request to the data sharing platform based on the first block height range, and receive target compressed block data corresponding to the first block height range returned by the data sharing platform;

[0016] A verification unit, used for decompressing the target compressed block data and performing data verification on the decompressed target block data;

[0017] An updating unit is used to synchronously update the local blockchain data based on the target block data when the data verification result is qualified.

[0018] Optionally, in some embodiments, the blockchain node data synchronization device provided by the present disclosure further includes:

[0019] A first acquisition subunit is used to acquire and locally store snapshot data when it is detected that snapshot data exists in a target node in the preset blockchain network, wherein the snapshot data is backup data of the blockchain data stored in the target node at a preset time;

[0020] The computing unit comprises:

[0021] A second acquisition subunit, used to acquire second block height information corresponding to the snapshot data;

[0022] The first calculation subunit is used to calculate a first block height range corresponding to the block data to be synchronized based on the second block height information and the first block height information.

[0023] Optionally, in some embodiments, the snapshot data includes initial snapshot data and a plurality of version update data blocks, and the second acquisition subunit includes:

[0024] A first acquisition module is used to acquire generation time information of each version update data block;

[0025] An update module, used to determine, according to the generation time information, a target version update data block whose generation time is closest to the current time;

[0026] The first determination module is used to determine the second block height information according to the target version update data block.

[0027] Optionally, in some embodiments, the first acquiring subunit includes:

[0028] A second acquisition module is used to acquire a first data volume of the snapshot data when it is detected that the target node in the preset blockchain network has snapshot data;

[0029] A sending module, used for sending the first data volume and the block height information of the snapshot data to the data sharing platform for data volume comparison;

[0030] The storage module is used to obtain the snapshot data and store the snapshot data locally when it is determined that the first data volume is not greater than the second data volume of the compressed block file of the corresponding block height according to the data volume comparison result returned by the data sharing platform.

[0031] Optionally, in some embodiments, the data sharing platform further returns the first hash data of the target compressed block data in response to the block data download request, and the verification unit includes:

[0032] A decompression subunit, used for decompressing the target compressed block data to obtain target block data;

[0033] A processing subunit, configured to perform hash processing on the target block data to obtain second hash data;

[0034] The first determination subunit is used to compare the first hash data with the second hash data, and determine a data verification result for the target block data according to the comparison result.

[0035] Optionally, in some embodiments, the determining subunit includes:

[0036] A second determination module is used to compare the first hash data with the second hash data, and when the first hash data is consistent with the second hash data, determine the third hash data of the last block in the target block data;

[0037] A receiving module, used to send the third hash data to multiple second nodes in the preset blockchain network for verification, and receive verification results returned by the multiple second nodes;

[0038] The third determination module is used to determine the data verification result of the target block data according to the verification results returned by the multiple second nodes.

[0039] Optionally, in some embodiments, the blockchain node data synchronization device provided by the present disclosure further includes:

[0040] A second calculation subunit is used to calculate the block hash of each block in the target block data, and obtain the parent hash corresponding to each block in the target block data;

[0041] A comparison subunit, used to compare each of the block hashes with the corresponding parent hash in the next block one by one;

[0042] A second determining subunit, configured to determine the third hash data of the last block in the target block data when the comparison results are exactly the same;

[0043] The third determination subunit is used to determine that the target block is an abnormal block when the block hash of the target block in the comparison result is different from the parent hash in the corresponding next block.

[0044] Optionally, in some embodiments, the first hash data and the second hash data both include multiple sub-hash data, and there is a corresponding relationship between the multiple sub-hash data included in the first hash data and the multiple sub-hash data included in the second hash data. The blockchain node data synchronization device provided by the present disclosure also includes:

[0045] a fourth determining subunit, configured to determine different target sub-hash data in the sub-hash data having a corresponding relationship when the first hash data is inconsistent with the second hash data;

[0046] a fifth determining subunit, configured to determine a second block height range corresponding to the target sub-hash data;

[0047] The third acquisition subunit is used to acquire block data corresponding to the second block height range in other data sharing platforms based on the second block height range.

[0048] Optionally, in some embodiments, the second sending unit includes:

[0049] A first sending subunit is used to send a block data download request to the data sharing platform, and receive a first compressed block data list returned by the data sharing platform, wherein the first compressed block data list includes a plurality of compressed block data, each compressed block data is obtained by compressing data corresponding to a plurality of blocks;

[0050] a sixth determining subunit, configured to determine, based on the first block height range, a second compressed block data list including a plurality of compressed block data in the first compressed block data list;

[0051] The second sending subunit is used to send the second compressed block data list to the data sharing platform, and receive the target compressed block data returned by the data sharing platform according to the second compressed block data list.

[0052] Optionally, in some embodiments, the present disclosure further provides a data export device, wherein the data export device specifically comprises:

[0053] An acquisition unit, used to acquire block data stored in the node, wherein the block data includes checksum data, block length data, and block serialized text data;

[0054] A writing unit, used for writing the block data into a database file with a preset storage space in order of block height;

[0055] A compression unit, configured to compress the database file to obtain a compressed block file when it is detected that the remaining storage space of the database file is insufficient to store the next block data and the last block data in the database file has been written;

[0056] A first generating unit, configured to generate index data corresponding to the block data in the database file;

[0057] A second generating unit, configured to generate fourth Hash data of the compressed block file and fifth Hash data of the index data;

[0058] An export unit is used to export the compressed block file, the index data, the fourth hash data and the fifth hash data to a data sharing platform.

[0059] Optionally, in some embodiments, the acquisition unit includes:

[0060] A first reading subunit, used for reading first checksum data and block length data from a block file storage database;

[0061] A second reading subunit is used to read the block serialized text data of corresponding length from the block file storage database according to the block length data;

[0062] A generating subunit, configured to generate second checksum data corresponding to the block serialized text data according to a preset checksum algorithm;

[0063] A loading subunit is used to load the first checksum data, the block length data and the block serialized text data as block data from the block file storage database when the first checksum data is the same as the second checksum data.

[0064] According to one aspect of the present disclosure, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor implements the blockchain node data synchronization method as described above when executing the computer program.

[0065] According to one aspect of the present disclosure, a storage medium is provided, wherein the storage medium stores a computer program, and when the computer program is executed by a processor, the blockchain node data synchronization method as described above is implemented.

[0066] According to one aspect of the present disclosure, a computer program product is provided, which includes a computer program, and the computer program is read and executed by a processor of a computer device, so that the computer device executes the blockchain node data synchronization method as described above.

[0067] The blockchain node data synchronization method provided by the embodiment of the present disclosure is applied to a first node in a preset blockchain network that needs to synchronize blockchain data. The method sends a blockchain data synchronization request for the preset blockchain network to a data sharing platform, and receives the first block height information returned by the data sharing platform. The data sharing platform receives and stores a compressed block file exported in real time by a second node in the preset blockchain network, where the second node is a node that can participate in the consensus process of the preset blockchain network; calculates a first block height range corresponding to the block data to be synchronized according to the status information of the locally stored block data and the first block height information; sends a block data download request to the data sharing platform based on the first block height range, and receives target compressed block data corresponding to the first block height range returned by the data sharing platform; decompresses the target compressed block data, and performs data verification on the decompressed target block data; when the data verification result is qualified, synchronizes and updates the local blockchain data based on the target block data.

[0068] In this way, by controlling the blockchain nodes to compress the block data synchronously when the block is generated and export it to the data sharing platform for storage, when the new node needs to synchronize the blockchain data, the compressed block data that needs to be loaded from the data sharing platform can be determined based on the block height difference between the existing data in the node and the latest block data imported from the data sharing platform. Then, the loaded compressed block data is decompressed and verified in one step to determine the reliability of the acquired block data. This avoids the process of loading and verifying a single block data, and can greatly improve the efficiency of blockchain node data synchronization.

[0069] Other features and advantages of the present disclosure will be described in the following description, and partly become apparent from the description, or understood by practicing the present disclosure. The purpose and other advantages of the present disclosure can be realized and obtained by the structures particularly pointed out in the description, claims and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0070] The accompanying drawings are used to provide further understanding of the technical solution of the present disclosure and constitute a part of the specification. Together with the embodiments of the present disclosure, they are used to explain the technical solution of the present disclosure and do not constitute a limitation on the technical solution of the present disclosure.

[0071] Figure 1A It is a schematic diagram of the architecture of the blockchain network provided by the present disclosure;

[0072] Figure 1B It is a schematic diagram of the block structure in the blockchain;

[0073] Figure 1C It is a schematic diagram of the block generation process in the blockchain;

[0074] Figure 2 It is a schematic diagram of a system architecture applied by the blockchain node data synchronization method according to an embodiment of the present disclosure;

[0075] Figure 3 It is a flowchart of a blockchain node data synchronization method provided by the present disclosure;

[0076] Figure 4 A schematic diagram of the process of storing block data on disk;

[0077] Figure 5 Another flowchart of the blockchain node data synchronization method provided by the present disclosure;

[0078] Figure 6 This is a schematic diagram of the specific structure of the block in the xxx.fdb file;

[0079] Figure 7A schematic diagram of a directory storing block files in a block file storage database;

[0080] Figure 8 It is a schematic diagram of another specific structure of the block in the xxx.fdb file;

[0081] Fig. 9 This is a schematic diagram of a file list in an exported folder in the present disclosure;

[0082] Fig.10 This is a schematic diagram of the scenario architecture for verifying the xxx.fdb file in the present disclosure;

[0083] Fig.11 A schematic diagram of the structure of a blockchain node data synchronization device provided in an embodiment of the present disclosure;

[0084] Fig.12 is a terminal structure diagram for implementing various methods according to an embodiment of the present disclosure;

[0085] Fig.13 It is a server structure diagram for implementing various methods according to an embodiment of the present disclosure. DETAILED DESCRIPTION

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

[0087] Before further describing the embodiments of the present disclosure in detail, the nouns and terms involved in the embodiments of the present disclosure are described. The nouns and terms involved in the embodiments of the present disclosure are subject to the following interpretations:

[0088] Blockchain: Blockchain is a chain of multiple blocks. Each block stores certain information, and they are connected into a chain in the order of their generation. This chain is stored in all servers in the blockchain network. As long as there is one server in the entire system that can work, the entire blockchain is safe. These servers are called nodes in the blockchain system, and they provide storage space and computing power support for the entire blockchain system. If you want to modify the information in the blockchain, you must obtain the consent of more than half of the nodes and modify the information in all nodes. These nodes are usually in the hands of different entities, so it is extremely difficult to tamper with the information in the blockchain. Compared with traditional networks, blockchain has two core characteristics: one is that data is difficult to tamper with, and the other is decentralization. Based on these two characteristics, the information recorded by the blockchain is more authentic and reliable, which can help solve the problem of people's distrust of each other.

[0089] Block: The unit of data storage on the chain in most blockchain implementations. The block number is the block height.

[0090] Node: A service in the blockchain. A blockchain is generally composed of multiple nodes, and each node starts a blockchain software service.

[0091] On-chain: Data is stored in the blockchain database.

[0092] Snapshot: The essence of a snapshot is data backup. Generally, the first snapshot is an exact copy of the data. Subsequent snapshots are based on the first snapshot and record the data blocks that have been changed or added during this period. Snapshots are usually used for version control or to restore recently modified data.

[0093] During the operation of the blockchain network, new blocks are constantly generated and added to the blockchain. After a period of operation, the amount of blockchain data will gradually accumulate, so that the data managed by a single full node may reach several TB (Terabyte, a unit of data storage). In some cases, multiple blockchains may run in a node, which will further increase the amount of blockchain data stored in the node.

[0094] In addition, since the consensus mechanism of blockchain requires that blockchain nodes that can become consensus nodes need to have the ability to verify newly generated blocks, and the verification process needs to use the block data of the blocks before the newly generated blocks, it means that if a node wants to become a consensus node, the block height of the blockchain stored in it must reach the block height of the current consensus node. In this way, if the new nodes in the blockchain network want to participate in the consensus process of the blockchain, they need to go through a long process of chasing blocks. The process of chasing blocks is specifically the process of data synchronization, that is, generating blocks one by one in the new nodes until the block height of the new nodes reaches the block height of the consensus node.

[0095] However, the block data synchronization method in the related art starts downloading block data from the genesis block after a new block is added. After downloading a block of data, in order to ensure the reliability of the block data, it also needs to be sent to other nodes for verification consensus. Only after the consensus is passed can a new block be generated. This process requires a large amount of data download and verification, resulting in a very low efficiency in chasing blocks. Moreover, while the newly added nodes are synchronizing block data, new blocks are still being generated. When the network bandwidth or stability is insufficient, the block data synchronization rate of the new node will be lower than the generation rate of the new block, which will cause the newly added node to be unable to reach a height that can participate in the consensus. In this regard, in order to solve the problem of low efficiency of block data synchronization, the present disclosure provides a blockchain node data synchronization method, in order to improve the efficiency of block data synchronization of newly added nodes in the blockchain, so that the newly added nodes can participate in the consensus as soon as possible.

[0096] System architecture and scenario description of the application of the embodiments of the present disclosure

[0097] Figure 1A It is a schematic diagram of the architecture of the blockchain network provided by the present disclosure. Specifically, the blockchain network can be a data sharing system 100, which includes multiple nodes 101, and the multiple nodes 101 can refer to each client in the data sharing system. Each node 101 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 intercommunication of information in the data sharing system, there can 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.

[0098] 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. A node identifier list as shown in the following table can be maintained in each node, and the node name and node identifier are stored in the node identifier list accordingly. Among them, the node identifier can be an IP (Internet Protocol, a protocol for interconnecting networks) address and any other information that can be used to identify the node. Table 1 only takes the IP address as an example for illustration.

[0099] Node Name Node ID Node 1 xxx.xxx.xxx.xxx Node 2 xxx.xxx.xxx.xxx … … Node N xxx.xxx.xxx.xxx

[0100] Table 1 Node identification diagram

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

[0102] 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:

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

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

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

[0106] The node 101 can be a terminal or a server. When the node 101 is a terminal, the node 101 can include desktop computers, laptop computers, PDAs (personal digital assistants), mobile phones, vehicle-mounted terminals, home theater terminals, dedicated terminals, etc. In addition, it can be a single device or a collection of multiple devices. The node 101 can communicate with other nodes in a wired or wireless manner to exchange data.

[0107] When node 101 is a server, node 101 may be a high-performance computer in the blockchain network, a cluster of multiple high-performance computers, a portion of a high-performance computer (e.g., a virtual machine), a combination of portions of multiple high-performance computers (e.g., virtual machines), etc.

[0108] Figure 2It is a schematic diagram of the system architecture applied by the blockchain node data synchronization method according to the embodiment of the present disclosure. It includes a data sharing system 100, a public network disk 200 and a newly added node 102. The data sharing system 100 has been introduced and will not be repeated here. The public network disk 200 can be a device for providing shared data storage services, which can be a terminal or a server; in the embodiment of the present disclosure, the public network disk 200 is specifically used to receive and store the compressed block file exported by the node 101 in the data sharing system 100, and the public network disk 200 can be a node in the data sharing system 100, or a device outside the data sharing system 100. When the newly added node 102 is newly added to the data sharing system 100, if the node expects to become a consensus node to participate in the consensus, it is necessary to go through the data synchronization process to achieve the local block height to catch up with the block height of the consensus node in the data sharing system 100. The newly added node 102 here is just an example, and it can also be other nodes that have joined the data sharing system 100, but the block height is lower than the block height of the consensus node, and other nodes that need to synchronize block data. Likewise, the newly added node 102 may be a server or a terminal.

[0109] The blockchain node data synchronization method provided in the present disclosure can be specifically applied to the above-mentioned newly added node 102. When the blockchain node data synchronization method provided in the present disclosure is applied to the newly added node 102, the newly added node 102 can send a blockchain data synchronization request for the data sharing system 100 to the public network disk 200, and receive the first block height information returned by the public network disk 200. The public network disk 200 receives and stores the compressed block file exported in real time by the node 101 in the data sharing system, and the node 101 is a node that can participate in the consensus in the data sharing system 100 (that is, it may be a consensus node or not a consensus node). Then, the newly added node 102 calculates the first block height range corresponding to the block data to be synchronized according to the status information of the locally stored block data and the first block height information. Further, the newly added node 102 sends a block data download request to the public network disk 200 based on the first block height range, and receives the target compressed block data corresponding to the first block height range returned by the public network disk 200. Afterwards, the newly added node 102 decompresses the received target compressed block data and performs data verification on the decompressed target block data. When the data verification result is qualified, the newly added node 102 synchronously updates the local blockchain data based on the target block data.

[0110] The embodiments of the present disclosure can be applied in a variety of scenarios, such as in a scenario where a new node is added to a blockchain network to synchronize blockchain data, or in a scenario where a node that has already stored some blockchain data in a blockchain network synchronizes blockchain data.

[0111] General description of the disclosed embodiments

[0112] According to an embodiment of the present disclosure, a method for synchronizing blockchain node data is provided. The method can be used in the aforementioned scenario of synchronizing blockchain data by adding a new node in the blockchain network, or in the scenario of synchronizing blockchain data by a node that has already stored some blockchain data in the blockchain network.

[0113] like Figure 3 As shown, it is a flowchart of the blockchain node data synchronization method provided by the present disclosure. The method can be applied to a blockchain node data synchronization device, which can be integrated in a computer device, and the computer device can specifically be a node in a blockchain network to be synchronized with blockchain data. The blockchain node data synchronization method may include:

[0114] Step 310, sending a blockchain data synchronization request for a preset blockchain network to a data sharing platform, and receiving the first block height information returned by the data sharing platform.

[0115] In the embodiment of the present disclosure, a blockchain node data synchronization method is provided that can improve the efficiency of blockchain data synchronization. Specifically, by providing a data sharing solution adapted to blockchain file storage, a blockchain node is allowed to share the original data of the node in real time to a public network disk for sharing by other nodes. In the sharing process, data compression is used to reduce the amount of data that needs to be transmitted, so as to further improve the efficiency of blockchain data synchronization. The following will take the application of the solution to the first node in a preset blockchain network as an example to introduce the blockchain data synchronization method provided by the present disclosure in detail.

[0116] The preset blockchain network can be any type of blockchain, such as a public chain, a private chain or a consortium chain, and can be Changan Chain. The preset blockchain network includes multiple nodes, each of which maintains a ledger, namely, a blockchain. Some of the multiple nodes determine multiple consensus nodes by staking virtual resources and voting by all nodes in the blockchain network. The consensus nodes participate in block generation and block verification and receive corresponding rewards. The preset blockchain network is an open network that encourages more nodes to join the preset blockchain network and participate in consensus to further improve the degree of decentralization of the blockchain network and improve the efficiency of event processing in the blockchain network. When a new node joins the preset blockchain network, it needs to synchronize blockchain data until the block data height in the node reaches the block height of the blockchain in the consensus node in the preset blockchain network before it can participate in the consensus process of block generation and verification.

[0117] The first node in this embodiment can be a node in the preset blockchain network that needs to synchronize block data, specifically a node newly added to the preset blockchain network, in which no block data has been stored; it can also be a node that has been in the preset blockchain network for a period of time and has some block data, but the block height is still lower than the block height of the block in the consensus node in the preset blockchain network. If the first node wants to participate in the consensus process of the preset blockchain network, it is necessary to synchronize blockchain data. At this time, a blockchain data synchronization request for the preset blockchain network can be sent to the data sharing platform to obtain blockchain data from the data sharing platform. Among them, the data sharing platform here can be the aforementioned network public disk 200. Specifically, the data sharing platform can be a decentralized file storage platform for objects in need to freely access the files stored therein; in the disclosed embodiment, the data sharing platform can be specifically an InterPlanetary File System (IPFS). The data sharing platform can store compressed block files exported by nodes in the aforementioned preset blockchain network, and can also store compressed block files exported by nodes in other blockchain networks.

[0118] After receiving the blockchain data synchronization request for the preset blockchain network sent by the first node, the data sharing platform can send the currently stored block height information of the preset blockchain network to the first node, which can be referred to as the first block height information. Specifically, the data sharing platform can send a file list of compressed block files exported by the second node in the preset blockchain network and stored in the data sharing platform to the first node, and the first node determines the first block height information based on the file list. Among them, the second node in the preset blockchain network can specifically be a consensus node in the preset blockchain network, or other nodes in the preset blockchain that may become consensus nodes and participate in consensus.

[0119] In some embodiments, the process of the second node exporting the compressed block file to the data sharing platform includes the following steps:

[0120] Get the block data stored in the node, which includes checksum data, block length data, and block serialized text data;

[0121] Write the block data into a database file with preset storage space in order of block height;

[0122] When it is detected that the remaining storage space of the database file is insufficient to store the next block of data and the last block of data in the database file has been written, the database file is compressed to obtain a compressed block file;

[0123] Generate index data corresponding to the block data in the database file;

[0124] generating fourth hash data of the compressed block file and generating fifth hash data of the index data;

[0125] The compressed block file, the index data, the fourth hash data, and the fifth hash data are exported to the data sharing platform.

[0126] Among them, in the second node in the blockchain, the blockchain data can be specifically divided into database data and file data. Among them, the database data can specifically be the data stored after the blockchain operation. The data may be modified later after being written. In the blockchain, a non-relational database (KVDB, such as leveldb) is generally used for storage, and the data contained therein specifically includes state data, block index data, etc. The file data specifically includes blocks, transactions, and historical read-write sets. The data volume of this data is large, and it continues to expand with the operation of the blockchain and the continuous increase of blocks. Moreover, this data is read-only and not modified, and is generally stored in the form of file storage (BFDB). In this solution, the block data can specifically be only file data, and the block data in the second node of the preset blockchain can be stored in the block file storage database. The block data can specifically include checksum data, block length data, and block serialized text data. Among them, the checksum data is used to verify whether the read block data is complete when reading block data; the block length data is used to guide the read data length when reading block data; the block serialization text data can be the text obtained by serializing various types of data in the block, where various types of data can include block header data, multiple event data and multiple other object data.

[0127] When the second node exports blockchain data to the data sharing platform, it can first obtain the block data stored in the block file storage database in the node, and then write the obtained block data into the database file with preset storage space in the order of block height. If the second node exports blockchain data to the data sharing platform for the first time, it can also first create an export data folder, and then create multiple database files that can store preset storage space data in the export data folder, and then write the block data obtained from the block file storage database into the database file one by one according to the block height.

[0128] Among them, the second node exports blockchain data to the data sharing platform, and can start exporting from the genesis block or from a block at a specific height. That is, the range of the exported blockchain file can be customized. When exporting from a block at a specific height, the block data can be written to the database file starting from the block data corresponding to the block at the specific height. When writing block data into the database file, the difference between the amount of data of the next block data to be written and the amount of data in the remaining space in the database file can be continuously detected. When it is detected that the amount of data of the next block data to be written is greater than the amount of data in the remaining space in the database file, the writing of block data in the current database file is terminated after the current block data is written, and the next block data to be written is written into the next database file. At the same time, the file name of the database file is generated according to the last block data written in the database file.

[0129] After completing the writing of the block data of a database file, the database file can be further compressed to obtain the corresponding compressed block file. The algorithm used by the second node to compress the database file can be any compression algorithm, which is not limited here. At the same time, the second node can also generate index data of the database file, and then generate hash data of the compressed block file and index data respectively. Finally, the compressed block file, index data and hash data of the two are exported to the data sharing platform.

[0130] In some embodiments, obtaining block data stored in a node includes:

[0131] Reading first checksum data and block length data from the block file storage database;

[0132] Read the block serialized text data of the corresponding length from the block file storage database according to the block length data;

[0133] Generate second checksum data corresponding to the block serialized text data according to a preset checksum algorithm;

[0134] When the first checksum data is identical to the second checksum data, the first checksum data, the block length data, and the block serialization text data are loaded from the block file storage database as the block data.

[0135] Among them, in the embodiment of the present disclosure, the storage of block data in the block file storage database is stored in the order of the aforementioned checksum data, block length data, and block serialized text data. When the second node reads the block data from the block file storage database and writes it into the database file, it can first read the first checksum data and block length data from the block file storage database. Then, according to the block length data, the block serialized text data of the corresponding length is read from the block file storage database. Furthermore, a preset checksum algorithm can be used to generate the second checksum data corresponding to the read block serialized text data, and then the first checksum data and the second checksum data are further compared.

[0136] When the comparison determines that the first checksum data and the second checksum data are the same, it means that the read block data is correct. At this time, the first checksum data, block length data and block serialization text data can be loaded from the block file storage database, and then the first checksum data, block length data and block serialization text data are written into the database file in sequence.

[0137] Among them, in some embodiments, before the second node in the preset blockchain exports the compressed block file, index data and hash data of the two to the data sharing platform, the second node can also export the compressed block file, index data and hash data of the two to other nodes in the preset blockchain network for verification. When the verification is passed, the second node exports the compressed block file, index data and hash data of the two to the data sharing platform to avoid the occurrence of malicious behavior by a single node and ensure the reliability of the blockchain data exported to the data sharing platform.

[0138] Step 320: Calculate a first block height range corresponding to the block data to be synchronized according to the state information of the locally stored block data and the first block height information.

[0139] Among them, after receiving the first block height information returned by the data sharing platform, the first node can further calculate the first block height range corresponding to the block data to be synchronized based on the status information of the locally stored block data and the first block height information. For example, when the first node is a newly added node in the preset blockchain network, that is, no blockchain data is stored in the first node, then it can be determined that the first block height range corresponding to the block data to be synchronized is from the genesis block to the first block height.

[0140] In some cases, after entering the preset blockchain network, the first node may have obtained some block data by other means, such as by obtaining snapshot data of other nodes, so that the block height of the locally stored blockchain has reached a certain height. For example, if the block height of the locally stored blockchain is 5, and the first block height is 100, then it can be determined that the first block height range to be synchronized is 6 to 100. That is, in the disclosed embodiment, when a node needs to synchronize blockchain data, it does not necessarily have to start synchronization from the genesis node, but can perform customized data synchronization, avoiding repeated data downloading and synchronization, thereby improving the efficiency of data synchronization.

[0141] In some embodiments, before calculating the first block height range corresponding to the block data to be synchronized according to the state information of the locally stored block data and the first block height information, the method further includes:

[0142] When it is detected that snapshot data exists in the target node in the preset blockchain network, the snapshot data is obtained and stored locally, and the snapshot data is the backup data of the blockchain data stored in the target node at the preset time;

[0143] Calculating the first block height range corresponding to the block data to be synchronized according to the state information of the locally stored block data and the first block height information, including:

[0144] Get the second block height information corresponding to the snapshot data;

[0145] A first block height range corresponding to the block data to be synchronized is calculated based on the second block height information and the first block height information.

[0146] In the disclosed embodiment, before sending a blockchain data synchronization request to the data sharing platform, the first node may also first detect whether there is snapshot data for each node in the preset blockchain network. In some cases, if the latest snapshot data exists in other nodes in the preset blockchain network, the first node can directly obtain the snapshot data of the node and quickly start a new node based on the snapshot data of the node, thereby greatly improving the efficiency of blockchain data synchronization. However, as new blocks are constantly generated with the operation of the blockchain network, the status of each node in the blockchain network is constantly changing. Moreover, generating the snapshot data of the node requires consuming certain resources and may not necessarily generate benefits, so the node is not very motivated to generate snapshots. As a result, the snapshot data of the node cannot be obtained in many cases, or the snapshot data is relatively old, and even if the snapshot data of the node is obtained, a long block chasing process is still required.

[0147] In the disclosed embodiment, since customized block data can be obtained from the data sharing platform, fast blockchain data synchronization can be achieved by combining the existing snapshot data of the existing nodes (i.e., the second node) in the preset blockchain network and the customized block data. Specifically, it is possible to first detect whether there is snapshot data in each node in the preset blockchain network. When it is detected that there is snapshot data in the target node in the preset blockchain network, the snapshot data can be obtained from the target node and stored locally. In general, in order to improve the efficiency of downloading snapshot data from the target node, the target node will also compress the snapshot data to a certain extent before transmitting it. After obtaining the compressed snapshot data from the target node, the compressed snapshot data can be further decompressed to obtain the snapshot data. The snapshot data is then stored in the local block file database.

[0148] After obtaining the snapshot data, the second block height information corresponding to the snapshot data can be determined, and then the first block height range corresponding to the block data to be synchronized can be calculated based on the second block height information and the first block height information. For example, if the second block height information corresponding to the snapshot data is 95, then the first block height range corresponding to the block data to be synchronized is 96 to 100. In this way, the efficiency of blockchain data synchronization can be further improved by combining snapshot synchronization with customized block data synchronization.

[0149] In some embodiments, the snapshot data includes initial snapshot data and multiple version update data blocks, and obtaining the second block height information corresponding to the snapshot data includes:

[0150] Get the generation time information of each version update data block;

[0151] Determine the target version update data block whose generation time is closest to the current time according to the generation time information;

[0152] The second block height information is determined according to the target version update data block.

[0153] In the disclosed embodiment, due to the characteristics of snapshot data, generally, when generating the initial snapshot data, the snapshot data will back up the detailed information of the data to obtain an exact copy. Then, as the version is iterated, the data blocks that have been changed or added during the version iteration are continuously recorded based on the previous version. Therefore, the snapshot data of the target node obtained by the first node may specifically include the initial snapshot data and multiple version update data blocks.

[0154] Therefore, when determining the second block height information corresponding to the snapshot data of the target node, the last version update data block can be determined first. Specifically, the generation time of each version update data block can be obtained first, and then the target version update data block with the latest generation time, that is, the generation time closest to the current time can be determined based on the generation time. Then, the second block height information is determined based on the information in the target version update data block with the generation time closest to the current time. In this way, the second block height information of the locally stored blockchain data can be directly determined without restoring the complete backup data of the target node, which can greatly improve the determination time of the second block height information, thereby improving the efficiency of blockchain data synchronization.

[0155] In some embodiments, when it is detected that snapshot data exists in a target node in a preset blockchain network, the snapshot data is obtained and stored locally, including:

[0156] When it is detected that snapshot data exists in the target node in the preset blockchain network, a first data volume of the snapshot data is obtained;

[0157] Sending the first data volume and the block height information of the snapshot data to the data sharing platform for data volume comparison;

[0158] When it is determined that the first data volume is not greater than the second data volume of the compressed block file of the corresponding block height according to the data volume comparison result returned by the data sharing platform, the snapshot data is obtained and stored locally.

[0159] In an embodiment of the present disclosure, when it is detected that there is a target node with snapshot data in the preset blockchain network, the snapshot data can be further compared with the compressed block file of the corresponding block height in the data sharing platform. Wherein the corresponding block height here specifically refers to the corresponding block height range, for example, the highest block height in the snapshot data is 95, then the corresponding block height range is 0 to 95. Specifically, the first data volume of the snapshot data can be obtained first, and then the first data volume and the corresponding block height range are sent to the data sharing platform for data volume comparison. If the data volume of the snapshot data is less than or equal to the compressed block file of the corresponding height range in the data sharing platform, the snapshot data can be downloaded and stored locally, otherwise, there is no need to download the snapshot data, but directly obtain all the block data from the data sharing platform for synchronization. In an embodiment of the present disclosure, when the data processing efficiency of the first node is high, that is, the efficiency of verifying the synchronized data is high, the efficiency of the blockchain data synchronization of the first node is limited by the download efficiency of the block data or snapshot data. At this time, the method of blockchain data synchronization can be determined by comparing the snapshot data with the data volume of the compressed block file in the corresponding block height range, which can further improve the efficiency of blockchain data synchronization of the first node.

[0160] Step 330: Send a block data download request to the data sharing platform based on the first block height range, and receive target compressed block data corresponding to the first block height range returned by the data sharing platform.

[0161] After determining the first block height range corresponding to the block data to be synchronized, the data sharing platform can be requested to download the corresponding block data based on the first block height range. After receiving the block data download request sent by the first node, the data sharing platform can query the target compressed block data corresponding to the first block height range in the stored compressed block data, and then return the target compressed block data to the first node.

[0162] In some embodiments, sending a block data download request to a data sharing platform based on a first block height range, and receiving target compressed block data corresponding to the first block height range returned by the data sharing platform, includes:

[0163] Sending a block data download request to the data sharing platform, and receiving a first compressed block data list returned by the data sharing platform, wherein the first compressed block data list includes a plurality of compressed block data, each compressed block data being obtained by compressing data corresponding to a plurality of blocks;

[0164] Determining a second compressed block data list including a plurality of compressed block data in the first compressed block data list based on the first block height range;

[0165] The second compressed block data list is sent to the data sharing platform, and the target compressed block data returned by the data sharing platform according to the second compressed block data list is received.

[0166] Among them, as mentioned above, when the second node in the preset blockchain exports block data to the data sharing platform, it writes the block data into the database file and then compresses the database file to obtain compressed block data. That is, each compressed block data corresponds to a database file, and each database file also contains block data of multiple blocks. That is, each compressed block data corresponds to a certain block height range. In the embodiment of the present disclosure, when the data sharing platform receives a block data download request sent by the first node, the first compressed block data list recording all compressed block data in the data sharing platform can be sent to the first node. After receiving the first compressed block data list, the first node can determine one or more compressed block data in the first compressed block data list according to the first block height range. When multiple compressed block data are determined, the second compressed block data list can be executed.

[0167] Then, the first node can send the second compressed block data list to the data sharing platform, and receive the target compressed block data returned by the data sharing platform according to the second compressed block data list. For example, when the first block height range is 80 to 100, if the received first compressed block data list contains 10 compressed block data, the block height ranges corresponding to these compressed block data are 0 to 9, 10 to 19, ... 80 to 89, 90 to 100. Then, according to the first block height range, the last two compressed block data can be determined as the target compressed block data, and these two target compressed block data constitute the second compressed block data list.

[0168] Step 340: decompress the target compressed block data, and perform data verification on the decompressed target block data.

[0169] After receiving the target compressed block data returned by the data sharing platform, the target compressed block data can be further decompressed. Specifically, the compression algorithm used to compress the block data can be obtained according to the naming information of the target compressed block data, and then the corresponding decompression algorithm can be obtained, and then the corresponding decompression algorithm can be used to decompress and obtain the target block data.

[0170] Among them, from the above introduction, it can be known that when the second node exports blockchain data to the data sharing platform, it compresses the database file storing multiple block data to obtain the corresponding compressed block data. Therefore, the target block data obtained by decompressing the target compressed block data here can also be one or more database files, each of which also contains multiple block data.

[0171] After decompressing the target block data, the target block data can be further verified to ensure the reliability of the downloaded block data. In the related art, when synchronizing blockchain data for nodes to be synchronized with blockchain data in a preset blockchain network, it is necessary to download and verify the block data one by one. Both data download and verification consume a lot of time, resulting in very low efficiency of blockchain data synchronization. In the disclosed embodiment, after obtaining the block data of multiple blocks that need to be synchronized, data verification can be performed on multiple block data that need to be synchronized at the same time, thereby greatly reducing the time consumption of block data verification. In addition, since the block data is also compressed when the blockchain data is exported to the data sharing platform in this solution, the amount of block data that needs to be downloaded can be reduced, further improving the efficiency of blockchain data synchronization.

[0172] In some embodiments, the data sharing platform, in response to the block data download request, further returns the first hash data of the target compressed block data, decompresses the target compressed block data, and performs data verification on the decompressed target block data, including:

[0173] Decompressing the target compressed block data to obtain the target block data;

[0174] Performing hash processing on the target block data to obtain second hash data;

[0175] The first hash data is compared with the second hash data, and a data verification result of the target block data is determined according to the comparison result.

[0176] According to the above introduction, when the second node exports blockchain data to the data sharing platform, it will not only export the compressed block data and index data corresponding to the database file to the data sharing platform, but also generate hash data of the compressed block data and index information, and export the hash data of the compressed block data and index information to the data sharing platform. The hash data of the compressed block data can be used to verify the compressed block data to verify the reliability of the compressed block data, avoid data errors caused by abnormal data transmission, and avoid data errors caused by abnormal behavior of malicious nodes.

[0177] Therefore, in the disclosed embodiment, when the data sharing platform receives the blockchain data download request sent by the first node, in addition to returning the target compressed block data to the first node, it also returns the first hash data to the first node, where the first hash data can specifically be the hash data corresponding to the target compressed block data. In this way, after the first node decompresses the target compressed block data to obtain the target block data, it can further perform hash processing on the decompressed target block data to obtain the second hash data. Then, the first node can perform data verification on the target block data according to the received first hash data and the generated second hash data. Specifically, the first hash data can be compared with the second hash data, and then the data verification result of the target block data can be determined according to the comparison result. For example, when the comparison result determines that the first hash data and the second hash data are the same, the data verification result of the target block data is determined to be verified; when the comparison result determines that the first hash data and the second hash data are different, the data verification result of the target block data is determined to be verified. Failed.

[0178] In some embodiments, comparing the first hash data with the second hash data, and determining a data verification result for the target block data according to the comparison result, includes:

[0179] Compare the first hash data with the second hash data, and when the first hash data is consistent with the second hash data, determine the third hash data of the last block in the target block data;

[0180] Sending the third hash data to multiple second nodes in a preset blockchain network for verification, and receiving verification results returned by the multiple second nodes;

[0181] The data verification result of the target block data is determined according to the verification results returned by the multiple second nodes.

[0182] In the embodiment of the present disclosure, after the first node compares the received first hash data with the second hash data obtained by hashing the received target compressed block data to determine that the first hash data and the second hash data are consistent, the first node must further send the hash data of the last block in the target data to a node in the preset blockchain network for verification to determine the data verification result of the target block data.

[0183] Specifically, when the first hash data is compared with the second hash data, and when it is determined that the first hash data and the second hash data are consistent, the third hash data of the last block in the target block data can be determined. Then, the third hash data is sent to multiple second nodes in the preset blockchain network for verification, and the verification results returned by the multiple second nodes are received. Then, the data verification result of the target block data can be further determined based on the verification results returned by the multiple second nodes.

[0184] Among them, since the second node in the preset blockchain network is a node that can participate in consensus, the block height in the second node must be greater than or equal to the height of the last block in the target block data, that is, the second node also stores the hash corresponding to the last block. Therefore, the second node can verify the received third hash data according to the hash corresponding to the last block stored in the node. When there is a verification result of the second node greater than a preset proportion in the verification result returned by the second node, it can be determined that the verification result of the data verification of the target block data is a verification pass. In the disclosed embodiment, the reliability of the synchronized blockchain data is further improved by further verifying the hash data of the last block in the target block data through the nodes in the blockchain network.

[0185] In some embodiments, before determining the third hash data of the last block in the target block data, the method further includes:

[0186] Calculate the block hash of each block in the target block data, and obtain the parent hash corresponding to each block in the target block data;

[0187] Compare each block hash with the corresponding parent hash in the next block one by one;

[0188] When the comparison results are exactly the same, determine the third hash data of the last block in the target block data;

[0189] When the block hash of the target block in the comparison result is different from the parent hash in the corresponding next block, the target block is determined to be an abnormal block.

[0190] Among them, in the embodiment of the present disclosure, before obtaining the third hash data of the last block in the target block data, each block in the target block data can be self-checked. Specifically, a hash algorithm can be used to calculate the corresponding block hash for each block. Then the block hash of each block is compared with the parent hash stored in the next block. Here, the parent hash is the hash corresponding to the parent block. In theory, if the data of the block is not abnormal, the parent hash stored in the next block should be the same as the block hash of the current block. Therefore, if the comparison result determines that the block hash of each block is exactly the same as the parent hash of the next block, the third hash data of the last block in the target block data can be further determined, and then the third hash data is sent to multiple second nodes in the preset blockchain network for verification. If there is a block hash of a target block in the comparison result that is different from the parent hash in the corresponding next block, it is determined that the target block is an abnormal block, and it is necessary to use other methods to obtain the block data corresponding to the block.

[0191] In some embodiments, the first hash data and the second hash data both include multiple sub-hash data, and there is a corresponding relationship between the multiple sub-hash data included in the first hash data and the multiple sub-hash data included in the second hash data. After comparing the first hash data with the second hash data, the method further includes:

[0192] When the first hash data and the second hash data are inconsistent, determining target sub-hash data that are different in the corresponding sub-hash data;

[0193] Determine the second block height range corresponding to the target sub-hash data;

[0194] Based on the second block height range, block data corresponding to the second block height range is obtained in other data sharing platforms.

[0195] Among them, since the target block data may include multiple database files, each database file contains data corresponding to multiple blocks. Therefore, the first hash data corresponding to the target block data may include multiple sub-hash data. Similarly, hashing the target block data can also be performed on the multiple database files contained in the target block data to obtain multiple sub-hash data. Moreover, the number of sub-hash data contained in the first hash data and the second hash data is consistent and one-to-one corresponding. In addition, in the embodiment of the present disclosure, when the preset blockchain network exports blockchain data to a data sharing platform, it can export blockchain data to multiple data sharing platforms to avoid the problem that the blockchain data cannot be synchronized normally due to data anomalies in a single data sharing platform.

[0196] In this way, when it is determined that the first hash data and the second hash data are inconsistent, there may be further target sub-hash data that is different in the corresponding sub-hash data. Then, the second block height range corresponding to the target sub-hash data can be further determined, and based on the second block height range, block data corresponding to the second block height range can be obtained from other data sharing platforms. In this way, even if data anomalies occur in a data sharing platform, blocks with data anomalies can be verified through data verification, and then the abnormal block data can be re-obtained from other data sharing platforms, thereby ensuring the stability of blockchain data synchronization.

[0197] Step 350: When the data verification result is qualified, the local blockchain data is synchronously updated based on the target block data.

[0198] When the data verification result of the target block data is qualified, the local blockchain data of the first node can be further synchronized and updated according to the target block data obtained and decompressed from the data sharing platform. Specifically, the data corresponding to the multiple blocks contained in the target block data can be stored on the disk, thereby realizing the synchronization of the blockchain data of the first node.

[0199] like Figure 4As shown, it is a schematic diagram of the process of storing block data on disk. As shown in the figure, multiple blocks in the target block data can be submitted to the node database 400 in the first node. The node database 400 includes block file storage stored on disk, specifically including block database 410, state database 420, history database 430, result database 440 and event database 450. After the block is submitted to the node database, the block header file storage index and the transaction file storage index are further stored in the block database 410, the time state key-value pair and the custom state data are stored in the state database 420, the state correction history, account modification history and contract call history are stored in the history database 430, the contract result file storage index is stored in the result database 440, and the event log is stored in the event database 450. When it is necessary to query the on-chain data, the queried data can be exported to the cache and then output to the query object.

[0200] In summary, the blockchain node data synchronization method provided by the present disclosure is adopted, by sending a blockchain data synchronization request for a preset blockchain network to a data sharing platform, and receiving the first block height information returned by the data sharing platform, the data sharing platform receives and stores the compressed block file exported in real time by the second node in the preset blockchain network, the second node is a node that can participate in the consensus process of the preset blockchain network; the first block height range corresponding to the block data to be synchronized is calculated according to the status information of the locally stored block data and the first block height information; based on the first block height range, a block data download request is sent to the data sharing platform, and the target compressed block data corresponding to the first block height range returned by the data sharing platform is received; the target compressed block data is decompressed, and the decompressed target block data is verified; when the data verification result is qualified, the local blockchain data is synchronized and updated based on the target block data.

[0201] In this way, by controlling the blockchain nodes to compress the block data synchronously when the block is generated and export it to the data sharing platform for storage, when the new node needs to synchronize the blockchain data, the compressed block data that needs to be loaded from the data sharing platform can be determined based on the block height difference between the existing data in the node and the latest block data imported from the data sharing platform. Then, the loaded compressed block data is decompressed and verified in one step to determine the reliability of the acquired block data. This avoids the process of loading and verifying a single block data, and can greatly improve the efficiency of blockchain node data synchronization.

[0202] The embodiments of the present disclosure are described in detail in combination with specific application scenarios.

[0203] like Figure 5As shown, it is another flow chart of the blockchain node data synchronization method provided by the present disclosure. The method will be described in detail by taking the blockchain node data synchronization method applied to adding a new node in the blockchain to synchronize blockchain data as an example. The method specifically includes the following steps:

[0204] Step 501: existing nodes in the blockchain write block file data into a block file storage database according to a preset format.

[0205] Among them, in the disclosed embodiment, the account book data in the blockchain can be divided into database data and block file data. Database data (KVDB storage) mainly includes modifiable data such as status data and block index data; file data (BFDB storage) includes unmodified data such as blocks, transactions, and historical read-write sets. A block file storage database is set in the existing nodes in the blockchain network. When a new block is generated in the blockchain network, the block file data of the block can be stored in the block file storage database in a certain format. In the disclosed embodiment, the file data stored in BFDB can be exported to a shared data server for sharing. When a new node is added to the blockchain network, the new node can download the file data stored in BFDB from the shared data server, and then generate the corresponding database data stored in KVDB according to the downloaded BFDB file data. In this way, when the new node is synchronized with the blockchain data, it is not necessary to download the database data stored in KVDB, thereby further reducing the amount of data that needs to be downloaded and improving the efficiency of blockchain data synchronization. The blockchain in the present disclosure can be specifically Changan Chain (ChainMaker).

[0206] Specifically, the block file data stored in the block file storage database has the following settings:

[0207] 1. The file name is 20 bytes long, for example, xxxxxxxxxxxxxxxxxxxxx; then, add .fdb (fileDB, database file) as the suffix of the file name. For example, the file name of a block file data is 000000000000000000001.fdb, and the block file data here can be referred to as xxx.fdb file in the future. The file name of the xxx.fdb file is set to the height of the first block stored in the file, which is converted according to the above file name rules. This setting allows the object to directly see the xxx.fdb file where the block data is located through the file.

[0208] For example: the xxx.fdb file contains 5 blocks with heights 0, 1, 2, 3, and 4, so the file name is 00000000000000000000.fdb.

[0209] 2. xxx.fdb file size: The xxx.fdb file that stores blocks has a certain size limit. For example, the size of each xxx.fdb file is limited to 1024MB (megabits), regardless of how many blocks are stored in the file.

[0210] 3. The xxx.fdb file is set with the corresponding database data, specifically the corresponding index information. The structure of the index information is as follows:

[0211]

[0212]

[0213] As shown in Table 1 below, it is a schematic diagram of the xxx.fdb file structure. The table shows two xxx.fdb files, each of which contains 5 blocks. The first xxx.fdb file is named 000000000000000000000.fdb, which contains blocks with block heights of 0, 1, 2, 3, and 4. The xxx.fdb file also contains index information of the objects contained in the file.

[0214]

[0215] Table 1xxx.fdb file structure diagram

[0216] like Figure 6 As shown in FIG. 6 , it is a schematic diagram of the specific structure of a block in the xxx.fdb file. As shown in the figure, the xxx.fdb file 600 contains block serialization texts 610 corresponding to multiple blocks (only two are shown in the figure, and there can be multiple blocks in practice). In each block serialization text 610, a block header serialization text 611, multiple transaction data serialization texts 612, and multiple other object serialization texts 613 are included.

[0217] In addition, after the block data is written into the xxx.fdb file in the above format, a directory for storing block files in the block file storage database can also be generated. Figure 7 As shown in the figure, it is a schematic diagram of the directory of block file storage in the block file storage database. Among them, 00000000000000000019.fdb.END in the file data is the xxx.fdb file being written. When the size of the file reaches the limited size, it will be changed to 00000000000000000019.fdb, and a new xxx.fdb.END file will be generated at the same time. Leveldb is used in the database data to store the index information of the block.

[0218] Step 502: An existing node in the blockchain creates an export folder and writes the block files in the local block file storage database into the export folder.

[0219] In the disclosed embodiment, after the existing nodes in the blockchain generate new blocks and store the corresponding data in the block file storage database according to the above-mentioned set format, they can further export the block files in the block file storage database to the shared data server for sharing. Specifically, the existing nodes in the blockchain can first create an export folder, which can be named export_chain, and then write the block files in the local block file storage database into the export folder for further export. In order to ensure the accuracy of data reading and writing in the process of writing the block files in the local block file storage database into the export folder, the specific structure of the block in the xxx.fdb file can be further adjusted, specifically, the checksum data (checksum) and block length data can be added before the block header. Figure 8 FIG. 6 is a schematic diagram of another specific structure of a block in a xxx.fdb file. As shown in the figure, the xxx.fdb file 600 contains a plurality of complete block data 800 (only two are shown in the figure, but there can be more in practice), and each complete block data 800 contains checksum data 810, block length data 820, and block serialization text 610.

[0220] The checksum data can be calculated by using a cyclic redundancy check (CRC) algorithm, and the length of the checksum data can be 4 bits. The block length data can be a 10-bit value (capable of recording the length of the serialized data of a 1000MB block), which records the text length of the written block. For example, if the serialized block size is 10MB, the text of the block length data is 10485760.

[0221] Then, when the existing nodes in the blockchain read the block file from the block file storage database and write it to the export folder, it can be specifically read from the file header. First read the checksum data, then read the block length data, and convert the block length data into a numerical value, which is the length data of the block data of the current block. Then, the text of the specified length can be read according to the length data to obtain the text stored in the xxx.fdb file after the block serialization text. Then, based on this text, the new checksum data is calculated by the CRC algorithm, and the calculated checksum data is compared with the read checksum data. When the two are consistent, the block data read out on the surface is complete. Then, read the remaining block data in the remaining xxx.fdb file in sequence according to the above reading method. If an error occurs during the reading process, it means that the data is damaged later, then the reading of the data is terminated, and the subsequent xxx.fdb file text is discarded.

[0222] When the existing nodes in the blockchain write the read block data into the export folder, they still write it in the format of the xxx.fdb file. When writing the block into the xxx.fdb file, you can write the checksum data first, then the block length data, and finally the block text data. If an error occurs during the writing process, the writing is terminated directly. When writing again, you need to restart the node and re-read and write. For example, after the writing of the block with a height of N is completed, the node device is powered off when writing the block with a height of (N+1), resulting in the block with a height of (N+1) not being written in full, for example, only 0.5 blocks are written. After the node device is restarted, when loading the latest block in the xxx.fdb file, the block with (N+1) will be discarded, and only the block with a height of N that has been stored will be recognized. In this way, the block with (N+1) needs to be re-read and written.

[0223] Step 503: The existing nodes in the blockchain compress the block files in the export folder to obtain compressed block data.

[0224] When the existing nodes in the blockchain write all the blocks in the block file storage database into the export folder, the xxx.fdb files in the export folder can be sorted according to the numerical size of the file name, and then each sorted xxx.fdb file can be compressed one by one. Specifically, the 7z compression algorithm can be used for compression, and of course other compression algorithms can also be used for compression. This is just an example. If the 7z compression algorithm is used for compression, the compressed block data corresponding to the xxx.fdb file can be obtained, which can also be specifically represented as xxx.fdb.7z file here.

[0225] Step 504: existing nodes in the blockchain generate index information of the block file, and generate hash data of the compressed block data and index information.

[0226] Furthermore, the existing nodes in the blockchain can also parse the xxx.fdb file to generate index information of the file, which can be specifically represented as the xxx.index file here.

[0227] Then, the contents of the xxx.fdb.7z file and the xxx.index file can be hashed respectively, and the hash values ​​obtained can be placed in the xxx.hash file respectively, where the first line is the hash of the xxx.fdb.7z file and the second line is the hash of the xxx.index file.

[0228] Then, the existing nodes in the blockchain can store the compressed block data, index information and hash number in the export folder, and can further generate the corresponding file list and store the file list in the export folder. Fig. 9 As shown, it is a schematic diagram of the file list in the export folder in the present disclosure.

[0229] Among them, in the embodiment of the present disclosure, the generation of the xxx.fdb.7z file, xxx.index file and xxx.hash file of each xxx.fdb file is independent and does not affect each other, so they can be generated in parallel. After all the above three files of the xxx.fdb file are generated, it is possible to further check whether there are omissions. If there are omissions, they can be regenerated once and overwrite the previous incomplete files.

[0230] In some embodiments, some data may be exported to the export folder before. Therefore, in the embodiment of the present disclosure, the xxx.fdb file of the specified interval may also be exported.

[0231] Step 505: The existing nodes in the blockchain export the compressed block data, index information, and hash data to a shared data server for storage.

[0232] After the existing nodes in the blockchain generate the xxx.fdb.7z file, xxx.index file and xxx.hash file of each xxx.fdb file, they can publish these files and place them in the network disk for the nodes in need to use. Specifically, these files can be sent to the shared data server for storage.

[0233] Step 506: When a new node is added to the blockchain, the new node sends a blockchain data synchronization request to the shared data server.

[0234] When a new node is added to the blockchain, if the new node wants to participate in the consensus of the blockchain, it is necessary to synchronize the blockchain data. In the disclosed embodiment, the new node can send a blockchain data synchronization request to the shared data server.

[0235] Step 507: The shared data server sends a block file list to the newly added node.

[0236] After receiving the blockchain data synchronization request sent by the newly added node, the shared data server can send the block file list to the newly added node. The block file list can be the aforementioned Fig. 9 The list shown in the figure can be specifically sent together when an existing node in the blockchain sends the xxx.fdb.7z file, the xxx.index file and the xxx.hash file to the shared data server, or it can be generated by the shared data server itself according to the stored block data.

[0237] Step 508 , the newly added node determines the target block file to be downloaded in the block file list, and downloads the target compressed block data and the corresponding hash data corresponding to the target block file from the shared data server.

[0238] After receiving the block file list, the newly added node can determine the target block file to be downloaded according to the block file list. In this embodiment, the newly added node does not store any blockchain data, so all xxx.fdb.7z files, xxx.index files and xxx.hash files stored in the shared data server can be downloaded according to the block file list.

[0239] Step 509: The newly added node decompresses the target compressed block data to obtain a target block file, and calculates hash data of the target block file.

[0240] After the newly added node downloads the target block file (including xxx.fdb.7z file, xxx.index file and xxx.hash file), it is necessary to further verify the downloaded target block file. Specifically, the xxx.fdb.7z file and xxx.index file can be verified.

[0241] Specifically, the specific process of verifying the xxx.fdb.7z file and the xxx.index file may be to first perform hash processing on the two files to obtain corresponding hash data.

[0242] Step 510: The newly added node performs a preliminary verification on the downloaded hash data based on the calculated hash data.

[0243] After the newly added node generates the hash data of the xxx.fdb.7z file and the xxx.index file, it can further compare the generated hash data with the downloaded hash data for preliminary verification. If the verification passes, further verification can be performed. If the verification fails, the xxx.fdb.7z file that fails the verification and the corresponding other files can be discarded, and then try to obtain the corresponding files from other channels.

[0244] Step 511, when the preliminary verification is qualified, the newly added node sends the hash data of the block with the highest block height in the target block file to the existing nodes in the blockchain for verification.

[0245] When the preliminary verification is qualified, the newly added node can decompress the xxx.fdb.7z file to obtain the corresponding xxx.fdb file. Then, the multiple blocks in the parsed file are hashed to obtain the block hash of each block. In addition, each block also stores the parent hash of the previous block. The block hash of each block is compared with the parent hash of the next block one by one. If the comparisons are all the same, the hash data of the target block with the highest block height in all xxx.fdb files can be further determined. The hash data of the target block is then sent to the existing nodes in the blockchain for verification.

[0246] like Fig.10 As shown, it is a schematic diagram of the scenario architecture for verifying the xxx.fdb file in the present disclosure. As shown in the figure, the newly added node 102 can first perform self-verification based on the block hash of each block in the xxx.fdb file and the parent hash in the block. Then, for the hash of the last block in each xxx.fdb file, it can be sent to multiple (only 2 are shown in the figure) other nodes 101 in the blockchain for verification. Specifically, the block height data and the corresponding hash data can be sent to the node 101 for verification, and the verification result returned by the node 101 is received.

[0247] Step 512: When the existing nodes in the blockchain pass the verification, the newly added nodes will store the target block file on disk.

[0248] When the existing nodes in the blockchain verify the hash data of the target block and the verification result is passed, the newly added node can store the target block file on the disk, thereby achieving the synchronization of the blockchain data of the newly added node.

[0249] Description of the apparatus and device of the present disclosure

[0250] It is to be understood that, although the steps in the above-mentioned flowcharts are sequentially displayed according to the characterization of arrows, these steps are not necessarily executed in sequence according to the order of arrow characterization. Unless there is a clear description in the present embodiment, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the above-mentioned flowcharts can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of the steps or stages in other steps.

[0251] It should be noted that in each specific embodiment of the present disclosure, when it comes to the need to perform relevant processing based on data related to the characteristics of the target object such as the target object attribute information or attribute information set, the permission or consent of the target object will be obtained first, and the collection, use and processing of these data will comply with the relevant laws, regulations and standards of the relevant region. In addition, when the embodiment of the present application needs to obtain the attribute information of the target object, the separate permission or separate consent of the target object will be obtained through a pop-up window or jump to a confirmation page. After clearly obtaining the separate permission or separate consent of the target object, the necessary target object-related data used to enable the normal operation of the embodiment of the present application will be obtained.

[0252] Fig.11 This is a schematic diagram of the structure of a blockchain node data synchronization device 1100 provided in an embodiment of the present disclosure. The device is applied to the first node in a preset blockchain network that needs to synchronize blockchain data, and the device includes:

[0253] The first sending unit 1110 is used to send a blockchain data synchronization request for a preset blockchain network to the data sharing platform, and receive the first block height information returned by the data sharing platform, the data sharing platform receives and stores the compressed block file exported in real time by the second node in the preset blockchain network, and the second node is a node that can participate in the consensus process of the preset blockchain network;

[0254] A calculation unit 1120, configured to calculate a first block height range corresponding to the block data to be synchronized according to the state information of the locally stored block data and the first block height information;

[0255] The second sending unit 1130 is used to send a block data download request to the data sharing platform based on the first block height range, and receive target compressed block data corresponding to the first block height range returned by the data sharing platform;

[0256] The verification unit 1140 is used to decompress the target compressed block data and perform data verification on the decompressed target block data;

[0257] The updating unit 1150 is used to synchronously update the local blockchain data based on the target block data when the data verification result is qualified.

[0258] Optionally, in some embodiments, the blockchain node data synchronization device provided by the present disclosure further includes:

[0259] A first acquisition subunit is used to acquire the snapshot data and store it locally when it is detected that the target node in the preset blockchain network has snapshot data, where the snapshot data is the backup data of the blockchain data stored in the target node at a preset time;

[0260] Computing unit, including:

[0261] A second acquisition subunit, used to acquire second block height information corresponding to the snapshot data;

[0262] The first calculation subunit is used to calculate a first block height range corresponding to the block data to be synchronized based on the second block height information and the first block height information.

[0263] Optionally, in some embodiments, the snapshot data includes initial snapshot data and a plurality of version update data blocks, and the second acquisition subunit includes:

[0264] A first acquisition module is used to acquire generation time information of each version update data block;

[0265] An update module, used to determine, according to the generation time information, a target version update data block whose generation time is closest to the current time;

[0266] The first determination module is used to determine the second block height information according to the target version update data block.

[0267] Optionally, in some embodiments, the first acquisition subunit includes:

[0268] A second acquisition module is used to acquire a first data volume of the snapshot data when it is detected that the target node in the preset blockchain network has snapshot data;

[0269] A sending module, used for sending the first data volume and block height information of the snapshot data to the data sharing platform for data volume comparison;

[0270] The storage module is used to obtain snapshot data and store the snapshot data locally when it is determined that the first data volume is not greater than the second data volume of the compressed block file of the corresponding block height according to the data volume comparison result returned by the data sharing platform.

[0271] Optionally, in some embodiments, the data sharing platform further returns the first hash data of the target compressed block data in response to the block data download request, and the verification unit includes:

[0272] A decompression subunit, used for decompressing the target compressed block data to obtain the target block data;

[0273] A processing subunit, configured to perform hash processing on the target block data to obtain second hash data;

[0274] The first determination subunit is used to compare the first hash data with the second hash data, and determine the data verification result of the target block data according to the comparison result.

[0275] Optionally, in some embodiments, determining a subunit includes:

[0276] A second determination module is used to compare the first hash data with the second hash data, and when the first hash data is consistent with the second hash data, determine the third hash data of the last block in the target block data;

[0277] A receiving module, used to send the third hash data to multiple second nodes in a preset blockchain network for verification, and receive verification results returned by the multiple second nodes;

[0278] The third determination module is used to determine the data verification result of the target block data according to the verification results returned by the multiple second nodes.

[0279] Optionally, in some embodiments, the blockchain node data synchronization device provided by the present disclosure further includes:

[0280] A second calculation subunit is used to calculate the block hash of each block in the target block data, and obtain the parent hash corresponding to each block in the target block data;

[0281] A comparison subunit is used to compare each block hash with the corresponding parent hash in the next block one by one;

[0282] A second determining subunit is used to determine the third hash data of the last block in the target block data when the comparison results are exactly the same;

[0283] The third determination subunit is used to determine that the target block is an abnormal block when the block hash of the target block in the comparison result is different from the parent hash in the corresponding next block.

[0284] Optionally, in some embodiments, the first hash data and the second hash data both include multiple sub-hash data, and there is a corresponding relationship between the multiple sub-hash data included in the first hash data and the multiple sub-hash data included in the second hash data. The blockchain node data synchronization device provided by the present disclosure also includes:

[0285] a fourth determining subunit, configured to determine, when the first hash data and the second hash data are inconsistent, different target sub-hash data in the sub-hash data having a corresponding relationship;

[0286] A fifth determination subunit, used to determine a second block height range corresponding to the target sub-hash data;

[0287] The third acquisition subunit is used to acquire block data corresponding to the second block height range in other data sharing platforms based on the second block height range.

[0288] Optionally, in some embodiments, the second sending unit includes:

[0289] A first sending subunit is used to send a block data download request to the data sharing platform, and receive a first compressed block data list returned by the data sharing platform, wherein the first compressed block data list includes a plurality of compressed block data, each compressed block data being obtained by compressing data corresponding to a plurality of blocks;

[0290] A sixth determining subunit, configured to determine, in the first compressed block data list, a second compressed block data list including a plurality of compressed block data based on the first block height range;

[0291] The second sending subunit is used to send the second compressed block data list to the data sharing platform, and receive the target compressed block data returned by the data sharing platform according to the second compressed block data list.

[0292] Optionally, in some embodiments, the present disclosure further provides a data export device, which specifically includes:

[0293] An acquisition unit, used to acquire block data stored in the node, the block data including checksum data, block length data and block serialized text data;

[0294] A writing unit, used to write the block data into a database file with a preset storage space in order of block height;

[0295] A compression unit, configured to compress the database file to obtain a compressed block file when it is detected that the remaining storage space of the database file is insufficient to store the next block of data and the last block of data in the database file has been written;

[0296] A first generating unit, used to generate index data corresponding to the block data in the database file;

[0297] A second generating unit, configured to generate fourth hash data of the compressed block file and fifth hash data of the index data;

[0298] The export unit is used to export the compressed block file, the index data, the fourth hash data and the fifth hash data to the data sharing platform.

[0299] Optionally, in some embodiments, the acquiring unit includes:

[0300] A first reading subunit, used for reading first checksum data and block length data from a block file storage database;

[0301] The second reading subunit is used to read the block serialized text data of the corresponding length from the block file storage database according to the block length data;

[0302] A generating subunit, used to generate second checksum data corresponding to the block serialized text data according to a preset check algorithm;

[0303] The loading subunit is used to load the first checksum data, the block length data and the block serialization text data from the block file storage database as the block data when the first checksum data is the same as the second checksum data.

[0304] Reference Fig.12 , Fig.12 The structural block diagram of the terminal 140 for implementing the blockchain node data synchronization method of the embodiment of the present disclosure is as follows: the terminal 140 includes: a radio frequency (RF) circuit 1210, a memory 1211, an input unit 1230, a display unit 1240, a sensor 1250, an audio circuit 1260, a wireless fidelity (WiFi) module 1270, a processor 1280, and a power supply 1290. Those skilled in the art can understand that Fig.12 The structure of the terminal 140 shown does not constitute a limitation on a mobile phone or a computer, and may include more or less components than shown in the figure, or combine certain components, or arrange the components differently.

[0305] The RF circuit 1210 may be used for receiving and sending signals during information transmission or communication. In particular, after receiving downlink information from the base station, the information is sent to the processor 1280 for processing. In addition, the uplink data is sent to the base station.

[0306] The memory 1211 can be used to store software programs and modules. The processor 1280 executes various functional applications of the terminal and blockchain node data synchronization by running the software programs and modules stored in the memory 1211.

[0307] The input unit 1230 may be used to receive input digital or character information and generate key signal input related to the terminal's settings and function control. Specifically, the input unit 1230 may include a touch panel 1231 and other input devices 1232 .

[0308] The display unit 1240 may be used to display input information or provided information and various menus of the terminal. The display unit 1240 may include a display panel 1241 .

[0309] The audio circuit 1260 , the speaker 1261 , and the microphone 1262 may provide an audio interface.

[0310] In this embodiment, the processor 1280 included in the terminal 140 can execute the blockchain node data synchronization method of the previous embodiment.

[0311] The terminal 140 of the embodiment of the present disclosure includes but is not limited to a mobile phone, a computer, an intelligent voice interaction device, a smart home appliance, a vehicle-mounted terminal, an aircraft, etc.

[0312] Fig.13 A block diagram of the structure of a portion of the server 110 for implementing the blockchain node data synchronization method of the embodiment of the present disclosure. The server 110 may have relatively large differences due to different configurations or performances, and may include one or more central processing units (CPUs) 1322 (e.g., one or more processors) and storage devices 1332, and one or more storage media 1330 (e.g., one or more mass storage devices) storing application programs 1342 or data 1344. Among them, the storage device 1332 and the storage medium 1330 may be short-term storage or permanent storage. The program stored in the storage medium 1330 may include one or more modules (not shown in the figure), each of which may include a series of instruction operations on the server 110. Furthermore, the central processor 1322 may be configured to communicate with the storage medium 1330 and execute a series of instruction operations in the storage medium 1330 on the server 110.

[0313] The server 110 may also include one or more power supplies 1326, one or more wired or wireless network interfaces 1350, one or more input and output interfaces 1358, and / or one or more operating systems 1341, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0314] The central processor 1322 in the server 110 can be used to execute the blockchain node data synchronization method of the embodiment of the present disclosure.

[0315] The disclosed embodiments also provide a storage medium for storing program code, and the program code is used to execute the blockchain node data synchronization method of each of the aforementioned embodiments.

[0316] The present disclosure also provides a computer program product, which includes a computer program. The processor of the computer device reads and executes the computer program, so that the computer device executes the above-mentioned blockchain node data synchronization method.

[0317] The terms "first", "second", "third", "fourth", etc. (if any) in the specification of the present disclosure and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present disclosure described herein can, for example, be implemented in an order other than those illustrated or described herein. In addition, the terms "comprises" and "comprising" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0318] It should be understood that in the present disclosure, "at least one (item)" means one or more, and "plurality" means two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the objects associated before and after are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0319] It should be understood that in the description of the embodiments of the present disclosure, the meaning of multiple (or multiple items) is more than two, greater than, less than, exceed, etc. are understood to not include the number, and above, below, within, etc. are understood to include the number.

[0320] In the several embodiments provided in the present disclosure, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic, for example, the division of units is only a logical function division, and there may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0321] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0322] In addition, each functional unit in each embodiment of the present disclosure may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0323] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present disclosure is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the various embodiments of the present disclosure. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (Read-Only Memory, referred to as ROM), random access memory (Random Access Memory, referred to as RAM), disk or optical disk and other media that can store program codes.

[0324] It should also be understood that the various implementations provided in the embodiments of the present disclosure can be combined arbitrarily to achieve different technical effects.

[0325] The above is a specific description of the implementation methods of the present disclosure, but the present disclosure is not limited to the above implementation methods. Technical personnel familiar with the art can also make various equivalent modifications or substitutions without violating the spirit of the present disclosure. These equivalent modifications or substitutions are all included in the scope defined by the claims of the present disclosure.

Claims

1. A blockchain node data synchronization method, characterized in that: The method is applied to a first node in a preset blockchain network that needs to synchronize blockchain data, and the method includes: Sending a blockchain data synchronization request for the preset blockchain network to a data sharing platform, and receiving the first block height information returned by the data sharing platform, wherein the data sharing platform receives and stores a compressed block file exported in real time by a second node in the preset blockchain network, wherein the second node is a node that can participate in the consensus process of the preset blockchain network; Calculating a first block height range corresponding to the block data to be synchronized according to the state information of the locally stored block data and the first block height information; Sending a block data download request to the data sharing platform based on the first block height range, and receiving target compressed block data corresponding to the first block height range returned by the data sharing platform; Decompressing the target compressed block data, and performing data verification on the decompressed target block data; When the data verification result is qualified, the local blockchain data is synchronously updated based on the target block data.

2. The method according to claim 1, characterized in that Before calculating the first block height range corresponding to the block data to be synchronized according to the state information of the locally stored block data and the first block height information, the method further includes: When it is detected that snapshot data exists in the target node in the preset blockchain network, the snapshot data is obtained and stored locally, where the snapshot data is the backup data of the blockchain data stored in the target node at a preset time; The calculating, according to the state information of the locally stored block data and the first block height information, a first block height range corresponding to the block data to be synchronized includes: Obtaining second block height information corresponding to the snapshot data; A first block height range corresponding to the block data to be synchronized is calculated based on the second block height information and the first block height information.

3. The method according to claim 2, characterized in that The snapshot data includes initial snapshot data and multiple version update data blocks, and obtaining the second block height information corresponding to the snapshot data includes: Get the generation time information of each version update data block; Determine, according to the generation time information, a target version update data block whose generation time is closest to the current time; The second block height information is determined according to the target version update data block.

4. The method according to claim 2, characterized in that: When it is detected that snapshot data exists in the target node in the preset blockchain network, the snapshot data is obtained and stored locally, including: When it is detected that snapshot data exists in the target node in the preset blockchain network, a first data volume of the snapshot data is obtained; Sending the first data volume and the block height information of the snapshot data to the data sharing platform for data volume comparison; When it is determined, according to the data volume comparison result returned by the data sharing platform, that the first data volume is not greater than the second data volume of the compressed block file of the corresponding block height, the snapshot data is acquired and stored locally.

5. The method according to claim 1, characterized in that: The data sharing platform further returns the first hash data of the target compressed block data in response to the block data download request, and the decompressing the target compressed block data and performing data verification on the decompressed target block data include: Decompressing the target compressed block data to obtain target block data; Performing hash processing on the target block data to obtain second hash data; The first hash data is compared with the second hash data, and a data verification result of the target block data is determined according to the comparison result.

6. The method according to claim 5, characterized in that The comparing the first hash data with the second hash data, and determining a data verification result of the target block data according to the comparison result, includes: Compare the first hash data with the second hash data, and when the first hash data is consistent with the second hash data, determine the third hash data of the last block in the target block data; Sending the third hash data to a plurality of the second nodes in the preset blockchain network for verification, and receiving verification results returned by the plurality of second nodes; A data verification result for the target block data is determined according to the verification results returned by the multiple second nodes.

7. The method according to claim 6, characterized in that Before determining the third hash data of the last block in the target block data, the method further includes: Calculate the block hash of each block in the target block data, and obtain the parent hash corresponding to each block in the target block data; Compare each of the block hashes with the corresponding parent hash in the next block one by one; When the comparison results are exactly the same, determining the third hash data of the last block in the target block data; When the block hash of the target block in the comparison result is different from the parent hash in the corresponding next block, the target block is determined to be an abnormal block.

8. The method according to claim 6, characterized in that The first hash data and the second hash data both include multiple sub-hash data, and there is a corresponding relationship between the multiple sub-hash data included in the first hash data and the multiple sub-hash data included in the second hash data, and after comparing the first hash data with the second hash data, the method further includes: When the first hash data is inconsistent with the second hash data, determining target sub-hash data that is different in the corresponding sub-hash data; Determine a second block height range corresponding to the target sub-hash data; Based on the second block height range, block data corresponding to the second block height range is obtained in other data sharing platforms.

9. The method according to claim 1, characterized in that: The sending a block data download request to the data sharing platform based on the first block height range, and receiving target compressed block data corresponding to the first block height range returned by the data sharing platform, includes: Sending a block data download request to the data sharing platform, and receiving a first compressed block data list returned by the data sharing platform, wherein the first compressed block data list includes a plurality of compressed block data, each compressed block data being obtained by compressing data corresponding to a plurality of blocks; Determine a second compressed block data list including a plurality of compressed block data in the first compressed block data list based on the first block height range; The second compressed block data list is sent to the data sharing platform, and the target compressed block data returned by the data sharing platform according to the second compressed block data list is received.

10. The method according to claim 1, characterized in that The process of the second node exporting the compressed block file to the data sharing platform includes the following steps: Obtaining block data stored in the node, wherein the block data includes checksum data, block length data, and block serialized text data; Writing the block data into a database file with a preset storage space in order of block height; When it is detected that the remaining storage space of the database file is insufficient to store the next block of data and the last block of data in the database file has been written, compressing the database file to obtain a compressed block file; Generate index data corresponding to the block data in the database file; generating fourth Hash data of the compressed block file, and generating fifth Hash data of the index data; The compressed block file, the index data, the fourth hash data and the fifth hash data are exported to a data sharing platform.

11. The method according to claim 10, characterized in that The obtaining of the block data stored in the node includes: Reading first checksum data and block length data from the block file storage database; Reading block serialized text data of corresponding length from the block file storage database according to the block length data; Generate second checksum data corresponding to the block serialized text data according to a preset check algorithm; When the first checksum data is the same as the second checksum data, the first checksum data, the block length data, and the block serialized text data are loaded from the block file storage database as block data.

12. A blockchain node data synchronization device, characterized in that: The device is applied to a first node in a preset blockchain network that needs to synchronize blockchain data, and the device includes: A first sending unit is used to send a blockchain data synchronization request for the preset blockchain network to a data sharing platform, and receive first block height information returned by the data sharing platform, wherein the data sharing platform receives and stores a compressed block file exported in real time by a second node in the preset blockchain network, wherein the second node is a node that can participate in the consensus process of the preset blockchain network; A calculation unit, configured to calculate a first block height range corresponding to the block data to be synchronized according to the state information of the locally stored block data and the first block height information; A second sending unit, configured to send a block data download request to the data sharing platform based on the first block height range, and receive target compressed block data corresponding to the first block height range returned by the data sharing platform; A verification unit, used for decompressing the target compressed block data and performing data verification on the decompressed target block data; An updating unit is used to synchronously update the local blockchain data based on the target block data when the data verification result is qualified.

13. A storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the blockchain node data synchronization method according to any one of claims 1 to 11 is implemented.

14. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, it implements the blockchain node data synchronization method according to any one of claims 1 to 11.

15. A computer program product, comprising a computer program, wherein the computer program is read and executed by a processor of a computer device, so that the computer device executes the blockchain node data synchronization method according to any one of claims 1 to 11.

Images