Blockchain data synchronization method and device, computer, storage medium and product

Abstract

The embodiment of the application discloses a kind of blockchain data synchronization method, device, computer, storage medium and product, the method includes: sending block information synchronization request to data sending node, sending block data synchronization request to data sending node;Obtain the block information sent by data sending node based on block information synchronization request;Block information includes the block header of the transaction block indicated by block information synchronization request, transaction read information, transaction write information and target node signature;The block header of the transaction block, transaction read information, transaction write information and target node signature are verified;When the block information of the transaction block is verified, the block data sent by data sending node based on block data synchronization request is obtained, and block data is written into blockchain.It can improve the efficiency of blockchain data synchronization by using the application.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a blockchain data synchronization method, apparatus, computer, storage medium and product. Background Technology

[0002] With the development of blockchain technology, more and more business systems are starting to use blockchain. In a blockchain system, it is necessary to ensure the consistency of the state among blockchain nodes. This means that, within a fault-tolerant range, the execution results of the same transaction block or the same transaction data among all blockchain nodes must be consistent. If consistency cannot be achieved, the transaction block cannot be recorded on the chain. However, in actual blockchain systems, due to network issues, server problems, or other potential issues, it is inevitable that one or more blockchain nodes will lag behind in data. When a blockchain node's data lags behind, it triggers a synchronization process. Synchronization means that the blockchain node obtains complete data from blockchain nodes with higher block heights than itself, in order to achieve a high degree of consistency with the transaction blocks stored by other blockchain nodes.

[0003] However, during synchronization, when a blockchain node differs significantly from other blockchain nodes, or when it is a newly joined node, the amount of transaction blocks it needs to synchronize is large, resulting in slow synchronization efficiency. This is especially true when each transaction block to be synchronized is large, and the number of transaction blocks to be synchronized is significant, requiring considerable time to complete the synchronization and thus reducing the overall efficiency of transaction block synchronization. Summary of the Invention

[0004] This application provides a blockchain data synchronization method, apparatus, computer, storage medium, and product, which can improve the efficiency of blockchain data synchronization.

[0005] This application provides a blockchain data synchronization method, which is executed by a data request node and includes:

[0006] Send a block information synchronization request to the data sending node, and send a block data synchronization request to the data sending node;

[0007] Obtain the block information sent by the data sending node based on the block information synchronization request; the block information includes the block header, transaction read information, transaction write information and target node signature of the requested transaction block indicated by the block information synchronization request;

[0008] Verify the block header, transaction read information, transaction write information, and target node signature of the requested transaction block;

[0009] When the block information of the requested transaction block is verified, the data sending node obtains the block data sent based on the block data and writes the block data into the blockchain.

[0010] This application provides a blockchain data synchronization method, which is executed by a data sending node and includes:

[0011] When a block information synchronization request is received from a data request node, the block header, transaction read information, transaction write information, and target node signature of the requested transaction block indicated in the block information synchronization request are obtained.

[0012] The block information of the requested transaction block is composed of the block header, transaction read information, transaction write information, and target node signature. The block information is then sent to the data request node so that the data request node can verify the block information of the requested transaction block.

[0013] When a block data synchronization request is received from a data request node, the block data of the requested transaction block indicated in the block data synchronization request is sent to the data request node so that the data request node can write the block data into the blockchain when the block information of the requested transaction block is verified.

[0014] This application provides a blockchain data synchronization device, which is suitable for data request nodes. The device includes:

[0015] The request sending module is used to send block information synchronization requests to data sending nodes and block data synchronization requests to data sending nodes.

[0016] The information acquisition module is used to acquire the block information sent by the data sending node based on the block information synchronization request; the block information includes the block header, transaction read information, transaction write information and target node signature of the requested transaction block indicated by the block information synchronization request;

[0017] The information verification module is used to verify the block header, transaction read information, transaction write information, and target node signature of the requested transaction block;

[0018] The data synchronization module is used to obtain the block data sent by the data sending node based on the block data synchronization request when the block information of the requested transaction block is verified, and write the block data into the blockchain.

[0019] The number of data sending nodes is N; N is a positive integer.

[0020] This request sending module can be used for:

[0021] Get the maximum synchronization height and the first block height, and get the number of data sending nodes N; the first block height refers to the maximum block height of the first transaction block included by the data request node;

[0022] The number of blocks to be synchronized for the data request node is determined based on the maximum synchronization height and the height of the first block.

[0023] Based on the number of blocks to be synchronized and N, determine the first block request range corresponding to each of the N data sending nodes;

[0024] Based on the first block request range corresponding to each of the N data sending nodes, block information synchronization requests are sent to each of the N data sending nodes, and block data synchronization requests are sent to each of the N data sending nodes.

[0025] The information verification module can be used for:

[0026] Obtain the transaction read set root from the transaction read information, generate the request write set root based on the transaction write information, and combine the request write set root with the transaction read set root to form the request read write set root;

[0027] Obtain the block read / write set root of the requested transaction block from the block header;

[0028] If the root of the requested read / write set is the same as the root of the block read / write set, and the signature verification of the target node is successful, then the block information of the requested transaction block is verified.

[0029] The information verification module can be used for:

[0030] The block header, transaction read information, and transaction write information of the requested transaction block are verified to obtain the information verification results;

[0031] Obtain the target consensus node corresponding to the target node signature of the requested transaction block, verify the target node signature based on the target consensus node, and obtain the signature verification result;

[0032] If the information verification result is "information verification passed" and the signature verification result is "signature verification passed", then it is determined that the block information verification of the requested transaction block has passed.

[0033] If the information verification result is a failure result, or the signature verification result is a failure result, then it is determined that the block information verification for the requested transaction block has failed.

[0034] The number of requested transaction blocks is M, where M is a positive integer;

[0035] When verifying the signature of the target node based on the target consensus node and obtaining the signature verification result, this information verification module can be used for:

[0036] If the p-th request transaction block is the first or last request transaction block among M request transaction blocks, then if the target consensus node corresponding to the target node signature of the p-th request transaction block is a data sending node, the signature verification failure result is determined as the signature verification result of the p-th request transaction block; if the target consensus node corresponding to the target node signature of the p-th request transaction block is not a data sending node, the signature verification success result is determined as the signature verification result of the p-th request transaction block; p is a positive integer less than or equal to M;

[0037] If the p-th request transaction block is neither the first nor the last of the M request transaction blocks, then if the target consensus node corresponding to the target node signature of the p-th request transaction block is the same as the target consensus node corresponding to the target node signature of the (p-1)-th request transaction block, the signature verification failure result is determined as the signature verification result of the p-th request transaction block; if the p-th target consensus node is different from the (p-1)-th target consensus node, the signature verification success result is determined as the signature verification result of the p-th request transaction block.

[0038] The number of requested transaction blocks is M, where M is a positive integer;

[0039] When verifying the signature of the target node based on the target consensus node and obtaining the signature verification result, this information verification module can be used for:

[0040] Deduplication is performed on the target consensus nodes corresponding to the M request transaction blocks to obtain the deduplicated nodes;

[0041] Get the number of first nodes after deduplication, and get the number of nodes that have passed consensus.

[0042] If the number of first nodes is less than the number of nodes that have passed consensus, then the signature verification failure result is determined as the signature verification result of M request transaction blocks;

[0043] If the number of first nodes is greater than or equal to the number of nodes that have passed consensus, then the signature verification result is determined as the signature verification result of M request transaction blocks.

[0044] The device also includes:

[0045] The information lookup module is used to look up the block information corresponding to the block data when it receives block data sent by the data sending node based on the block data synchronization request.

[0046] The data caching module is used to cache block data when block information is not found or when block information verification fails.

[0047] When the block information of the requested transaction block is verified, and the data synchronization module is used to obtain the block data sent by the data sending node based on the block data synchronization request, this module can be used for:

[0048] When the block information of the requested transaction block is verified, the cached block data is retrieved.

[0049] The number of requested transaction blocks is M, where M is a positive integer; the device also includes:

[0050] The write processing module is used to obtain the transaction write information of the p-th requested transaction block; p is a positive integer less than or equal to M.

[0051] The write processing module is also used to update the first state data according to the transaction write information of the p-th request transaction block if the transaction write information of the p-th request transaction block is data of the first type; the first type refers to the data type of the transaction write data.

[0052] The write processing module is also used to obtain the transaction write information of the (p+1)th request transaction block if the transaction write information of the pth request transaction block is data of the second type; the second type refers to the hash type.

[0053] The device further includes the following components when the block information of the requested transaction block is verified:

[0054] The range determination module is used to obtain the second block request range from the unsynchronized block range if there is an unsynchronized block range in the range of blocks to be synchronized; the range of blocks to be synchronized refers to the block height range of the transaction blocks that the data request node is missing;

[0055] The continued synchronization module is used to continue sending block information synchronization requests to the data sending node based on the second block request range, and to store the second block request range;

[0056] The continued synchronization module is also used to continue sending block data synchronization requests to the data sending node based on the second block request range when block data is written into the blockchain.

[0057] The device also includes:

[0058] The function update module is used to obtain the first block request range corresponding to the block information synchronization request and the block data synchronization request, and to obtain the functional block range associated with the block query function; the functional block range refers to the block height range of the transaction blocks targeted by the block query function.

[0059] This function update module is also used to update the function block range based on the first block request range when writing block data into the blockchain; the updated function block range includes the first block request range.

[0060] This application provides a blockchain data synchronization device, which is suitable for data sending nodes. The device includes:

[0061] The data acquisition module is used to acquire the block header, transaction read information, transaction write information, and target node signature of the requested transaction block indicated by the block information synchronization request when it receives a block information synchronization request sent by a data request node.

[0062] The information processing module is used to assemble the block header, transaction read information, transaction write information and target node signature of the requested transaction block into block information of the requested transaction block, and send the block information to the data request node so that the data request node can verify the block information of the requested transaction block;

[0063] The data sending module is used to send the block data of the requested transaction block indicated by the block data synchronization request to the data request node when it receives the block data synchronization request sent by the data request node, so that the data request node can write the block data into the blockchain when the block information of the requested transaction block is verified.

[0064] Specifically, when obtaining the block header, transaction read information, transaction write information, and target node signature of the requested transaction block indicated by the block information synchronization request, this data acquisition module can be used for:

[0065] Obtain the block header and target node signature of the requested transaction block indicated by the block information synchronization request;

[0066] Obtain the transaction data included in the requested transaction block, obtain the transaction read data based on the transaction data, perform hash processing on the transaction read data to obtain the transaction read set root corresponding to the transaction data, and determine the transaction read set root as the transaction read information of the requested transaction block;

[0067] Obtain transaction write data from the transaction data, and convert the transaction write data into transaction write information.

[0068] The number of requested transaction blocks is M, where M is a positive integer;

[0069] When converting transaction write data into transaction write information, this data acquisition module can be used for:

[0070] Get the transaction key data included in the transaction write data of the k-th requested transaction block, and get the transaction key data in the transaction write data corresponding to the first to the (k-1)-th requested transaction blocks respectively; k is a positive integer less than or equal to M; the block height of the k-th requested transaction block is less than the block height of the (k-1)-th requested transaction block.

[0071] If the first transaction key data includes the (k-1)th transaction key data, then the transaction write data of the kth request transaction block is hashed to obtain the transaction write information of the kth request transaction block.

[0072] If the first transaction key data is included in the (k-1)th transaction key data but not the kth transaction key data, then the transaction write data of the kth requested transaction block will be determined as the transaction write information of the kth requested transaction block.

[0073] One embodiment of this application provides a computer device, including a processor, a memory, and an input / output interface;

[0074] The processor is connected to a memory and an input / output interface, respectively. The input / output interface is used to receive and output data, the memory is used to store computer programs, and the processor is used to call the computer programs so that the computer device containing the processor executes the blockchain data synchronization method in one aspect of the embodiments of this application.

[0075] One aspect of this application provides a computer-readable storage medium storing a computer program adapted to be loaded and executed by a processor, so that a computer device having the processor performs the blockchain data synchronization method of one aspect of this application.

[0076] One aspect of this application provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in various optional embodiments of this application. In other words, when the computer instructions are executed by the processor, they implement the methods provided in various optional embodiments of this application.

[0077] Implementing the embodiments of this application will have the following beneficial effects:

[0078] In this embodiment, a block information synchronization request is sent to the data sending node, and a block data synchronization request is sent to the data sending node; the block information sent by the data sending node based on the block information synchronization request is obtained; the block information includes the block header, transaction read information, transaction write information, and target node signature of the requested transaction block indicated by the block information synchronization request; the block header, transaction read information, transaction write information, and target node signature of the requested transaction block are verified; when the block information of the requested transaction block is verified, the block data sent by the data sending node based on the block data synchronization request is obtained, and the block data is written into the blockchain. Through the above process, the synchronization of transaction blocks can be broken down into a block information synchronization process and a block data synchronization process. The block information synchronization process first synchronizes the block information of the transaction blocks that need to be synchronized. This block information includes the data required to verify a transaction block. Then, the complete block data of the transaction block is continuously synchronized. The block information synchronization process and the block data synchronization process are performed separately and independently. This allows data request nodes to synchronize block information based on the block information synchronization process first. Since the amount of block information is generally small, this improves the block synchronization efficiency of data request nodes. This allows data request nodes to quickly participate in the block consensus and block generation processes in the blockchain system, thereby improving the performance of the blockchain system. Furthermore, because the block information includes the data required to verify a transaction block, when data request nodes join the block consensus and block generation processes in the blockchain system based on the block information, the consistency of the ledger synchronization and the security of the ledger data can be guaranteed. Moreover, the data request node will also synchronize the complete data of the transaction block through the block data synchronization process. This block data synchronization process will not affect the operation of the data request node in the blockchain system, and can ensure the integrity of the ledger data in the data request node. Attached Figure Description

[0079] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0080] Figure 1 This is a blockchain system architecture diagram provided in an embodiment of this application;

[0081] Figure 2 This is a schematic diagram of a blockchain structure provided in an embodiment of this application;

[0082] Figure 3This is a schematic diagram of a blockchain data synchronization scenario provided in an embodiment of this application;

[0083] Figure 4 This is a flowchart of a blockchain data synchronization method provided in an embodiment of this application;

[0084] Figure 5 This is an example diagram of block information provided in an embodiment of this application;

[0085] Figure 6 This is a schematic diagram illustrating a specific process for blockchain data synchronization provided in an embodiment of this application;

[0086] Figure 7 This is a schematic diagram of a signature verification process provided in an embodiment of this application;

[0087] Figure 8 This is a flowchart of another blockchain data synchronization method provided in the embodiments of this application;

[0088] Figure 9 This is a schematic diagram of a block hashing scenario provided in an embodiment of this application;

[0089] Figure 10 This is an example diagram of a read / write set for a transaction provided in an embodiment of this application;

[0090] Figure 11 This is an example diagram of a block hashing process provided in an embodiment of this application;

[0091] Figure 12 This is a schematic diagram of another specific process for blockchain data synchronization provided in an embodiment of this application;

[0092] Figure 13 This is a schematic diagram of a transaction read / write set processing flow provided in an embodiment of this application;

[0093] Figure 14 This is an interactive example diagram of a blockchain data synchronization scenario provided in an embodiment of this application;

[0094] Figure 15 This is a schematic diagram of a blockchain data synchronization device provided in an embodiment of this application;

[0095] Figure 16 This is a schematic diagram of another blockchain data synchronization device provided in the embodiments of this application;

[0096] Figure 17 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0097] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0098] In this embodiment, if data of an object (such as a user) needs to be collected, a prompt interface or pop-up window will be displayed before and during the collection process. This prompt interface or pop-up window is used to inform the user that certain data is being collected. The data acquisition steps will only begin after the user confirms the prompt interface or pop-up window; otherwise, the process will end. Furthermore, the acquired user data will be used in reasonable and legal scenarios or for legitimate purposes. Optionally, in scenarios where user data needs to be used but user authorization has not been obtained, authorization can be requested from the user, and the user data will be used only after authorization is granted. In other words, the use of user data in this application complies with relevant laws and regulations.

[0099] In the embodiments of this application, please refer to Figure 1 , Figure 1 This is a blockchain system architecture diagram provided in an embodiment of this application, such as... Figure 1 As shown, the blockchain system 101 includes multiple blockchain nodes, such as... Figure 1 The diagram shows blockchain nodes 101a, 101b, and 101c. These blockchain nodes can interact with each other, and can perform block consensus and block generation. Each blockchain node can act as both a data request node and a data sender node. Simply put, a data request node is any blockchain node in the system whose maximum block height is less than the maximum synchronization height; that is, a data request node is a blockchain node in the system that needs to synchronize blocks. The maximum synchronization height refers to the maximum block height among the transaction blocks included in the blockchain system. A data sender node is a blockchain node that provides the data request node with relevant data (such as block information and block data) for the transaction blocks to be synchronized. Each blockchain node can include a transaction ledger, which is a ledger composed of transaction blocks in the blockchain system.

[0100] Among them, see Figure 2 , Figure 2 This is a schematic diagram of a blockchain structure provided in an embodiment of this application. For example... Figure 2As shown, a blockchain is composed of transaction blocks. Each transaction block includes two parts: a block header and a block body. The block header includes a timestamp, the current hash value, and the predecessor hash value. The timestamp records the generation time of the transaction block; the current hash value is the hash value of the transaction block, and in this application, the current hash value (i.e., the block hash) of a transaction block is used to indicate the transaction block; the predecessor hash value is the block hash of the block's predecessor; and the block body contains the transaction data stored in the block. Specifically, taking the addition of the second block to the blockchain as an example, the method for generating a new block is as follows:

[0101] When the first block 201 exists on the blockchain, it indicates the first transaction data generated by the first transaction. This first transaction data is the data (i.e., transaction data) stored in the block body of the first block 201. If a second transaction occurs, second transaction data will be generated through this second transaction. If the second transaction data is verified, a second block 202 will be generated from this second transaction data and added to the blockchain as the successor block to the first block 201. The timestamp included in the header of the second block 202 records the generation time of the second block 202; the current hash value is the hash value generated by the blockchain system using the data contained in the second block 202; the predecessor hash value is the block hash of the first block 201; and the block body of the second block 202 records the second transaction data.

[0102] Similarly, block 203 is added to the blockchain. Block 203 indicates the third transaction data generated by the third transaction. If a new transaction occurs in the transaction chain indicated by the blockchain, a subsequent block is generated and added to the blockchain in the same way as the above-mentioned method for generating new blocks.

[0103] pass Figure 2 The above process enables the generation of the blockchain and the uploading of blocks to the chain.

[0104] For details, please see Figure 3 , Figure 3 This is a schematic diagram of a blockchain data synchronization scenario provided in an embodiment of this application. For example... Figure 3As shown, data request node 301 can send a block information synchronization request to data sender node 302 and a block data synchronization request to data sender node 302. The sending times of the block information synchronization request and the block data synchronization request by data request node 301 do not affect each other; that is, the sending of the block information synchronization request by data request node 301 and the sending of the block data synchronization request by data sender node 301 are independent of each other. When data sender node 302 receives the block information synchronization request sent by data request node 301, it obtains the block data 303 of the requested transaction block 3031. This block data 303 includes, but is not limited to, the requested transaction block 3031, as well as the transaction read set and transaction write set of the transaction data in the block body. Data sender node 302 can generate block information 304 for the requested transaction block 3031 based on the block data 303. This block information 304 may include the block information of the requested transaction block 3031. The block information includes a block header, transaction read information, transaction write information, and the target node's signature. Block information 304 refers to the data required for block verification of the requested transaction block 3031. The transaction read information is generated from the transaction read set of the transaction data in the requested transaction block 3031, and the transaction write information is generated from the transaction write set of the transaction data in the requested transaction block 3031. The data sending node 302 can send block information 304 to the data requesting node 301. The data requesting node 301 can verify block information 304. When the data sending node 302 receives a block data synchronization request from the data requesting node 301, it obtains the block data 303 of the requested transaction block 3031 requested in the block data synchronization request and sends the block data 303 to the data requesting node 301. When data request node 301 receives block data 303, it can look up the detection result of the block information 304 corresponding to the block data 303. If the block information 304 is verified, the block data 303 is written into the blockchain 305. Here, blockchain 305 refers to the transaction ledger of data request node 301.

[0105] By splitting the block synchronization process into independent block information synchronization and block data synchronization processes, any blockchain node can primarily focus on the block information synchronization process when block synchronization is needed. Since the block information synchronized in this process includes the information required to verify a transaction block, a blockchain node can join the network through this process. Joining the network means that the blockchain node can participate in processes such as block consensus and block generation within the blockchain system. The amount of block information synchronized in the block information synchronization process is generally small; therefore, the time and resources consumed by the blockchain node during block information synchronization are also less, improving the efficiency of blockchain node joining the network. Simultaneously, based on the block data synchronization process, the blockchain node can achieve complete synchronization of transaction block data. In other words, this application improves the efficiency of blockchain node joining the network while ensuring data integrity.

[0106] It is understood that the blockchain node mentioned in the embodiments of this application can be a computer device, and the computer device in the embodiments of this application includes, but is not limited to, terminal devices or servers. In other words, the computer device can be a server or a terminal device, or a system composed of servers and terminal devices. Among them, the terminal device mentioned above can be an electronic device, including but not limited to mobile phones, tablets, desktop computers, laptops, handheld computers, in-vehicle devices, augmented reality / virtual reality (AR / VR) devices, head-mounted displays, smart TVs, wearable devices, smart speakers, digital cameras, webcams and other mobile internet devices (MIDs) with network access capabilities, or terminal devices in scenarios such as trains, ships, and flights. Among them, the server mentioned above can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, vehicle-to-everything (V2X) services, content delivery networks (CDNs), and big data and artificial intelligence platforms.

[0107] Optionally, the data involved in the embodiments of this application may be stored in a computer device or may be stored based on cloud storage technology, without any limitation.

[0108] Further, please see Figure 4 , Figure 4This is a flowchart illustrating a blockchain data synchronization method provided in an embodiment of this application. Figure 4 As shown, the blockchain data synchronization process is executed by the data request node, and includes the following steps:

[0109] Step S401: Send a block information synchronization request to the data sending node and a block data synchronization request to the data sending node.

[0110] In this embodiment, the data request node can obtain the maximum synchronization height and the first block height. The maximum synchronization height refers to the maximum block height of transaction blocks in the blockchain system, and the first block height refers to the maximum block height of the first transaction blocks included in the data request node. The data request node can determine the range of blocks to be synchronized based on the maximum synchronization height and the first block height, and divide the range of blocks to be synchronized into the first block request range and the unsynchronized block range. The data request node can send a block information synchronization request for the first block request range to the data sending node, and send a block data synchronization request for the first block request range to the data sending node. Here, the range of blocks to be synchronized refers to the range of block heights of the transaction blocks missing by the data request node, which can be denoted as [first block height + 1, maximum synchronization height]; the unsynchronized block range refers to the block height range outside the first block request range in the range of blocks to be synchronized. Optionally, the unsynchronized block range can also be empty, that is, the data request node can request the synchronization of all missing transaction blocks at once.

[0111] Optionally, the number of data sending nodes is N; N is a positive integer. The data requesting node can obtain the maximum synchronization height and the first block height, and obtain the number of data sending nodes N; the first block height refers to the maximum block height of the first transaction block included by the data requesting node. The data requesting node can determine the number of blocks to be synchronized based on the maximum synchronization height and the first block height. Specifically, the difference between the maximum synchronization height and the first block height can be used to determine the number of blocks to be synchronized, which represents the number of missing transaction blocks for the data requesting node. The data requesting node can determine the first block request range corresponding to each of the N data sending nodes based on the number of blocks to be synchronized and N. Specifically, the data requesting node can determine the unit synchronization quantity based on the number of blocks to be synchronized and N, which refers to the number of transaction blocks requested by a data sending node; based on the unit synchronization quantity, the first block request range corresponding to each of the N data sending nodes is determined from the range of blocks to be synchronized. Furthermore, a data request node can send block information synchronization requests and block data synchronization requests to each of the N data sending nodes based on the first block request range corresponding to each of the N data sending nodes. For example, if the first block request range corresponding to data sending node 1 is [1, 25] and the first block request range corresponding to data sending node 2 is [26, 50], then the data request node can send a block information synchronization request for the first block request range "[1, 25]" to data sending node 1, and a block data synchronization request for the first block request range "[1, 25]" to data sending node 2; the data request node can send a block information synchronization request for the first block request range "[26, 50]" to data sending node 2, and a block data synchronization request for the first block request range "[26, 50]" to data sending node 2.

[0112] Step S402: Obtain the block information sent by the data sending node based on the block information synchronization request; the block information includes the block header, transaction read information, transaction write information and target node signature of the requested transaction block indicated by the block information synchronization request.

[0113] In this embodiment, the data request node can obtain the block information sent by the data sending node based on the block information synchronization request. Specifically, when the data sending node receives a block information synchronization request, it can obtain the block data of the requested transaction block corresponding to the first block request range, generate block information of the requested transaction block data, and send the block information of the requested transaction block data to the data request node. The data request node can obtain the block information of the requested transaction block sent by the data sending node based on the block information synchronization request.

[0114] The number of requested transaction blocks can be M, where M is a positive integer. The data requesting node can obtain block information corresponding to each of the M requested transaction blocks. Each block information includes the block header, transaction read information (in this embodiment, the root of the transaction read set), transaction write information, and the target node's signature for the corresponding requested transaction block. For example, see... Figure 5 , Figure 5 This is an example diagram of block information provided in an embodiment of this application. For example... Figure 5 As shown, assuming M is 3, the M request transaction blocks include request transaction block 1, request transaction block 2, and request transaction block 3. The block information of request transaction block 1 includes the block header 5011, the transaction read set root 5012, and the target node signature (e.g., ...) of request transaction block 1. Figure 5 The blockchain node A's signature is shown in the diagram, along with the transaction write information for requesting transaction block 1; the block information for requesting transaction block 2 includes the block header 5021 of requesting transaction block 2, the transaction read set root 5022 of requesting transaction block 2, and the target node signature of requesting transaction block 2 (such as...). Figure 5 The block information for requesting transaction block 3 includes the block header 5031, the transaction read set root 5032, the target node signature, and the transaction write information. Optionally, in the block information, the transaction write information corresponding to each of the M requesting transaction blocks exists in the form of a write information set 504, and the target node signature corresponding to each of the M requesting transaction blocks exists in the form of a signature set 505. That is, the block information corresponding to the M requesting transaction blocks includes a write information set 504, a signature set 505, and the block header and transaction read set root corresponding to each of the M requesting transaction blocks.

[0115] Each block header may include, but is not limited to, a block identifier (ChainId), block height (BlockHeight), block hash (BlockHash), predecessor block hash (PreBlockHash), transaction root (TxRoot), transaction count (TxCount), and block read / write set root (RWSetRoot). Specifically, the block identifier is used to uniquely identify the corresponding transaction block; the block height indicates the height of the corresponding transaction block in the blockchain; the block hash indicates the corresponding transaction block and is used to associate it with adjacent transaction blocks; the predecessor block hash represents the block hash of the corresponding transaction block; the transaction root represents the hash value of the transaction data included in the corresponding transaction block; the transaction count represents the number of transaction data included in the corresponding transaction block; and the block read / write set root is a hash value obtained from the transaction read and write sets corresponding to the transaction data of the corresponding transaction block.

[0116] Optionally, when the data requesting node receives block information corresponding to M request transaction blocks, it can obtain the minimum block height and the first block height corresponding to the M block information. The first block height refers to the maximum block height among the transaction blocks included in the data requesting node's data. Further, if the minimum block height is greater than the first block height, and the minimum block height is adjacent to the first block height, it indicates that the transaction block indicated by the block information is the transaction block that the data requesting node currently needs to synchronize. That is, the transaction block indicated by the minimum block height is the next transaction block after the transaction block indicated by the first block height. Step S403 can then be executed to verify the M block information. For example, if the first block height is 100 and the minimum block height is 101, and the minimum block height "101" is greater than the first block height "100", and the minimum block height "101" is adjacent to the first block height "100", it means that the transaction block indicated by the block information is the successor transaction block of the transaction block currently included by the data request node.

[0117] If the minimum block height is less than or equal to the first block height, it indicates that there is a transaction block already included by the data request node in the transaction block indicated by the block information. The M block information is traversed sequentially until the height of the first block to be processed is determined. Step S403 is executed for the block information corresponding to the height of the first block to be processed, verifying the block information corresponding to this height until the synchronization of the M block information is completed. The height of the first block to be processed is greater than the height of the first block and is adjacent to the height of the first block. Specifically, step S403 can be executed for the block information corresponding to the maximum block height indicated by the M block information, from the height of the first block to the maximum block height indicated by the M block information. For example, if the M block information corresponds to the first block request range [1, 25] (i.e., the maximum block height indicated by the M block information is 25), and the height of the first block to be processed is 5, then the data request node can execute step S403 for the block information corresponding to the block height range [5, 25].

[0118] If the minimum block height is greater than the first block height, and the minimum block height is not adjacent to the first block height, it indicates that there are still missing transaction blocks between the transaction blocks corresponding to the M block information and the transaction blocks included in the data request node. The data request node can store the block information corresponding to the M request transaction blocks respectively until the block information corresponding to the second block height is processed. The data request node can obtain the block information corresponding to the M request transaction blocks respectively, and execute step S403 for the block information corresponding to the M request transaction blocks respectively, wherein the height of the second block to be processed is less than the minimum block height and is adjacent to the minimum block height. For example, if the minimum block height is 30 and the first block height is 10, it means that the data request node needs to first synchronize the block information corresponding to the block height range [11, 29], and then synchronize the first block request range. At this time, the second block to be processed has a height of 29. That is, when the data request node finishes processing the block information corresponding to the block height of 29, it executes step S403 for the block information corresponding to the M request transaction blocks respectively.

[0119] Step S403 verifies the block header, transaction read information, transaction write information, and target node signature of the requested transaction block.

[0120] In this embodiment, the data request node can verify the block information of the requested transaction block. If the block information verification is successful, step S404 is executed. Optionally, if the block information verification fails, the data request node can discard the block information and resend a block information synchronization request for the first block request range to the data sending node.

[0121] Specifically, the data requesting node can obtain the transaction read set root from the transaction read information, generate the request write set root based on the transaction write information, and combine the request write set root with the transaction read set root to form the request read-write set root, which is to perform hash processing on the request write set root and the transaction read set root to obtain the request read-write set root; obtain the block read-write set root of the request transaction block from the block header of the request transaction block; if the request read-write set root is the same as the block read-write set root, and the signature verification of the target node passes, then the block information verification of the request transaction block is determined to be successful; if the request read-write set root is different from the block read-write set root, or the signature verification of the target node fails, then the block information verification of the request transaction block fails.

[0122] Specifically, the data requesting node can verify the block header, transaction read information, and transaction write information of the requested transaction block to obtain the information verification result, as described above for verifying the root of the block read / write set; it can also obtain the target consensus node corresponding to the target node's signature of the requested transaction block, and verify the target node's signature based on the target consensus node to obtain the signature verification result. If both the information verification result and the signature verification result are successful, then the block information verification of the requested transaction block is determined to be successful; otherwise, if either the information verification result or the signature verification result is unsuccessful, then the block information verification of the requested transaction block is determined to be unsuccessful. Here, a successful information verification result means that the block header, transaction read information, and transaction write information have all been verified successfully; an unsuccessful information verification result means that the block header, transaction read information, and transaction write information have all been verified successfully; a successful signature verification result means that the target node's signature has been verified successfully; and a unsuccessful signature verification result means that the target node's signature has been verified successfully.

[0123] The number of requested transaction blocks is M, where M is a positive integer. When verifying the target node's signature based on the target consensus node and obtaining the signature verification result, a signature synchronization rule can be obtained. Based on the signature synchronization rule, the target node's signature is verified to obtain the signature verification result. This signature synchronization rule refers to the restrictions on the node signatures that make up the block information during block information synchronization. For example, in case ①, the signature synchronization rule is full signature synchronization, meaning that each block information requires all node signatures of the transaction block corresponding to that block information to be included. In this case, the data requesting node can obtain the target node signature of the p-th requested transaction block. If the number of target node signatures of the p-th requested transaction block satisfies (i.e., is greater than or equal to) the consensus pass threshold corresponding to the consensus algorithm, then the signature verification pass result is determined as the signature verification result of the p-th requested transaction block; if the number of target node signatures of the p-th requested transaction block does not satisfy (i.e., is less than) the consensus pass threshold corresponding to the consensus algorithm, then the signature verification failure result is determined as the signature verification result of the p-th requested transaction block. Where p is a positive integer less than or equal to M, consensus algorithm refers to the algorithm used in the blockchain system to reach consensus on transaction blocks, such as Proof of Work (POW) consensus algorithm and Practical Byzantine Fault Tolerance (PBFT) consensus algorithm.

[0124] In scenario ②, the signature synchronization rule includes that the node signatures in the first and last block information cannot be the signatures of the data sending node that sent M blocks of information, and that the node signatures in two adjacent blocks cannot be the same. In this case, the data requesting node can obtain the target node signature of the p-th request transaction block. If the p-th request transaction block is the first or last request transaction block among the M request transaction blocks, then if the target consensus node corresponding to the target node signature of the p-th request transaction block is a data sending node, the signature verification failure result is determined as the signature verification result of the p-th request transaction block; if the target consensus node corresponding to the target node signature of the p-th request transaction block is not a data sending node, the signature verification success result is determined as the signature verification result of the p-th request transaction block; p is a positive integer less than or equal to M.

[0125] If the p-th request transaction block is neither the first nor the last of the M request transaction blocks, then if the target consensus node corresponding to the target node signature of the p-th request transaction block is the same as the target consensus node corresponding to the target node signature of the (p-1)-th request transaction block, the signature verification failure result is determined as the signature verification result of the p-th request transaction block. If the p-th target consensus node is different from the (p-1)-th target consensus node, the signature verification success result is determined as the signature verification result of the p-th request transaction block. The p-th request transaction block is the next transaction block in the blockchain for the (p-1)-th target consensus node.

[0126] In scenario ③, the signature synchronization rule is that the number of blockchain nodes corresponding to the target node's signature in the M block information is greater than or equal to the number of consensus-passing nodes. In this case, the number of requesting transaction blocks is M, where M is a positive integer. The data requesting node can deduplicate the target consensus nodes corresponding to the M requesting transaction blocks to obtain deduplicated nodes; it then obtains the first node count of the deduplicated nodes and the number of consensus-passing nodes. This number refers to the threshold used by the consensus algorithm in the blockchain system to determine consensus passage, and can also be denoted as the aforementioned consensus passage threshold. Further, if the first node count is less than the number of consensus-passing nodes, the signature verification failure result is determined as the signature verification result of the M requesting transaction blocks; if the first node count is greater than or equal to the number of consensus-passing nodes, the signature verification success result is determined as the signature verification result of the M requesting transaction blocks.

[0127] Of course, the above are just examples of several signature synchronization rules, and you can configure signature synchronization rules according to your needs. Optionally, you can also use multiple signature synchronization rules at the same time, such as using the signature synchronization rules indicated by case ② and case ③ simultaneously. In this case, the data request node can first verify the signature of the target node through case ③. After the signature verification of M target nodes is successful, it can then verify the signature of each target node separately through case ② to obtain the signature verification result.

[0128] Optionally, when verification of a block fails, a third block request range can be determined based on the failed block information and M blocks. A block information synchronization request can then be sent to the data sending node based on this third block request range. The third block request range refers to the range from the block height corresponding to the failed block information to the maximum block height corresponding to the M requested transaction blocks.

[0129] Step S404: When the block information of the requested transaction block is verified, the data sending node obtains the block data sent based on the block data synchronization request and writes the block data into the blockchain.

[0130] In this embodiment, when a data requesting node receives block data from a data sending node for a first block request range, it can search for the verification result of the block information corresponding to the first block request range. If the verification of the block information corresponding to the first block request range passes, the block data is written into the blockchain. If the verification of the block information corresponding to the first block request range fails, or no verification result is found, the block data is cached until the verification of the block information corresponding to the first block request range passes, and then the block data is written into the blockchain. Specifically, when receiving block data sent by a data sending node based on a block data synchronization request, the node searches for the block information corresponding to the block data. If no block information is found, or the verification of the block information fails, the block data is cached. At this time, when the block information of the requested transaction block passes verification, the node retrieves the block data sent by the data sending node based on the block data synchronization request; when the block information of the requested transaction block passes verification, the node retrieves the cached block data.

[0131] When the block information of the requested transaction block is verified, the data request node can search for the block data corresponding to the first block request range. If the block data corresponding to the first block request range is found, the block data is written into the blockchain.

[0132] Optionally, when writing block data into the blockchain, the block data can be verified. If the verification passes, the block data is written into the blockchain. Since the block information corresponding to the block data has already been verified, a simple verification can be performed here, such as obtaining the transaction data included in the block data, hashing the transaction data to obtain the requested block body hash. If the requested block body hash is the same as the transaction root, the block data verification is considered successful. When there are multiple requested transaction blocks, each block data can be verified, and if the verification passes, the corresponding block data is written into the blockchain. Since the transaction blocks in the blockchain have a chain structure, when verifying the block data corresponding to M requested transaction blocks sequentially, if the verification of a certain block data fails, the verification of that block data and subsequent blocks can be stopped directly. Based on that block data and the M requested transaction blocks, a fourth block request range can be determined, and a block data synchronization request can be sent to the data sending node based on the fourth block request range. The fourth block request range refers to the range from the block height corresponding to the block data that failed to be verified to the maximum block height corresponding to the M request transaction blocks.

[0133] Optionally, the number of requested transaction blocks is M, where M is a positive integer. When the data request node verifies the information of M blocks, it can also synchronously update the state data of the blockchain based on the information of M blocks. Of course, the state data can be updated once for each block that is verified. Specifically, the data request node can obtain the transaction write information of the p-th requested transaction block; p is a positive integer less than or equal to M. If the transaction write information of the p-th requested transaction block is data of the first type, then the first state data is updated according to the transaction write information of the p-th requested transaction block. The first state data refers to the state data of the blockchain included by the data request node; the first type refers to the data type of the transaction write data. If the transaction write information of the p-th requested transaction block is data of the second type, then the transaction write information of the (p+1)-th requested transaction block is obtained; the second type refers to the hash type. When a transaction write information is data of the second type, it means that the transaction write information can be overwritten, that is, it is not written into the state data and will not affect the final state data. This method can improve the efficiency of state data updates. Here, the p-th request transaction block is the preceding transaction block of the (p+1)-th request transaction block in the blockchain. If the number of data sending nodes is N, then in step S403, based on the third block request range, a block information synchronization request is sent to the data sending node that sent the verification failed block information. By updating the state data, the accuracy of the data from the data request node during network access can be ensured.

[0134] Alternatively, the data requesting node can obtain the transaction write information of the p-th requested transaction block and update the first state data based on this information. Since the verification of the M blocks is performed sequentially according to block height, the state data can also be updated based on the transaction write information of each requested transaction block, ensuring the synchronization of the first state data of the data requesting node. Moreover, updating the state data based on the transaction write information of each requested transaction block ensures that even if some blocks fail verification during the verification of the M blocks, the first state data corresponds to the latest verified block information, improving the accuracy of the first state data. In this case, if the number of data sending nodes is N, then in step S403, a block information synchronization request can be sent to any data sending node based on the third block request range.

[0135] Optionally, when the block information of the requested transaction block is verified, if there are unsynchronized block ranges within the range of blocks to be synchronized, the data request node can obtain the second block request range from these unsynchronized block ranges. The range of blocks to be synchronized refers to the block height range of the transaction blocks that the data request node is missing. Based on the second block request range, a block information synchronization request is sent to the data sending node, the second block request range is stored, and the range of blocks to be synchronized is updated based on the second block request range. The updated range of blocks to be synchronized refers to the range other than the second block request range. When block data is written into the blockchain, a block data synchronization request is sent to the data sending node based on the second block request range.

[0136] Optionally, upon successful verification of the block information of the requested transaction block, the data request node can obtain the first block request range corresponding to the block information synchronization request and the block data synchronization request, and obtain the functional block range associated with the block query function. The functional block range refers to the block height range of the transaction block targeted by the block query function. When writing block data into the blockchain, the functional block range is updated based on the first block request range. The updated functional block range includes the first block request range. In other words, when the block information synchronization is successful, the data request node can join the network and operate, but it cannot provide business devices with the data query function for the requested transaction block corresponding to the first block request range for the time being. Only when the block data corresponding to the block information is successfully synchronized can the data query function for the requested transaction block corresponding to the first block request range be provided to business devices.

[0137] For details, please refer to Figure 6 , Figure 6 This is a schematic diagram illustrating a specific process for blockchain data synchronization provided in an embodiment of this application. For example... Figure 6 As shown, the blockchain data synchronization process is executed by the data request node, and includes the following steps:

[0138] Step S601: Obtain the request block information set; the request block set includes the block information corresponding to each of the M request transaction blocks.

[0139] In this embodiment of the application, the data request node can obtain the requested block information set (blocks), the process of which can be referred to Figure 4 The relevant description in step S402. Here, the first block request range is the range consisting of the first request height and the second request height, which can be denoted as [first request height, second request height], where the first request height refers to the minimum value in the first block request range (i.e., the aforementioned). Figure 4 The smallest block height shown in the figure), the second request height refers to the maximum value in the first block request range.

[0140] Step S602, initialize p.

[0141] In this embodiment of the application, the data request node can initialize p, and the initial value of p can be 1 or 0.

[0142] Step S603: Obtain the block information of the p-th request transaction block from the M block information.

[0143] In this embodiment, the data request node can obtain the block information of the p-th requested transaction block from M block information. If the initial value of p is 0, the process can be written as block_p = blocks[p]; if the initial value of p is 1, the process can be written as block_p = blocks[p-1]. For the convenience of subsequent scheme descriptions, all subsequent schemes are described with the initial value of p being 1.

[0144] Step S604: Obtain the block header, transaction read information, transaction write information, and target node signature from the block information of the p-th request transaction block.

[0145] In this embodiment, the data requesting node can obtain the block header, transaction read information, transaction write information, and target node signature from the block information of the p-th requested transaction block. This process can be found in [reference needed]. Figure 4 The relevant description in step S402.

[0146] Step S605: Obtain the height of the first block.

[0147] In this embodiment of the application, the data request node can obtain the first block height (LastHeight), which refers to the maximum block height of the transaction blocks included by the data request node.

[0148] Step S606: Detect whether the block height of the p-th request transaction block is the next block height after the first block height.

[0149] In this embodiment, the data request node can detect whether the block height (block_p.header.Height) of the p-th request transaction block is the next block height after the first block height, that is, detect whether LastHeight is equal to block_p.header.Height-1. If the block height of the p-th request transaction block is the next block height after the first block height, then step S609 is executed; if the block height of the p-th request transaction block is not the next block height after the first block height, then step S607 is executed. This process can be found in [reference needed]. Figure 4The relevant description in step S402.

[0150] Step S607: Detect whether the height of the first block is greater than the block height of the p-th request transaction block.

[0151] In this embodiment, the data request node can detect whether the height of the first block is greater than the block height of the p-th request transaction block, that is, whether LastHeight > block_p.header.Height holds true. If the height of the first block is greater than the block height of the p-th request transaction block, then step S614 is executed to obtain the next block information; if the height of the first block is less than the block height of the p-th request transaction block, then step S608 is executed to store and wait for the information of M blocks.

[0152] Step S608: Wait until the block information corresponding to the next block height of the first block height is obtained.

[0153] In this embodiment of the application, the data request node can store the block information corresponding to each of the M request transaction blocks until the block information corresponding to the height of the second block to be processed is processed. The data request node can then obtain the block information corresponding to each of the M request transaction blocks and execute step S602 for the block information corresponding to each of the M request transaction blocks.

[0154] Step S609: Verify the signature of the target node for the p-th request transaction block.

[0155] In this embodiment of the application, the data requesting node can verify the target node signature of the p-th request transaction block, as can be seen from... Figure 4 The relevant description in step S403.

[0156] Step S610: Check whether the signature of the p-th target node has been verified.

[0157] In this embodiment of the application, the data request node can detect whether the signature of the target node for the p-th request transaction block has been verified. If the verification is successful, step S611 is executed; if the verification fails, the third block request range is determined based on the block height of the p-th request transaction block and the block height of the M-th request transaction block, and a block information synchronization request is sent to the data sending node based on the third block request range.

[0158] Step S611: Generate the root of the request read / write set for the p-th request transaction block based on the p-th transaction read information and the p-th transaction write information.

[0159] In this embodiment of the application, the data request node can generate the root of the request read / write set for the p-th request transaction block based on the transaction read information and the transaction write information of the p-th request transaction block. For example... Figure 5 As shown, assuming the p-th requesting transaction block is requesting transaction block 1, the data requesting node can obtain the transaction read set root 5012 and transaction write information of requesting transaction block 1; hash the transaction write information to obtain the request write set root; hash the transaction read set root 5012 and the request write set root to obtain the request read-write set root (RWSetRoot). See [link to documentation] for details. Figure 4 The relevant description in step S403.

[0160] Step S612: Check whether the root of the p-th request read / write set is the same as the root of the block read / write set in the p-th block header.

[0161] In this embodiment, the data request node can detect whether the p-th request read / write set root is the same as the block read / write set root (block_p.header.RWSetRoot) in the p-th block header, that is, whether RWSetRoot is the same as block_p.header.RWSetRoot. If the p-th request read / write set root is the same as the block read / write set root in the p-th block header, then step S613 is executed; if the p-th request read / write set root is different from the block read / write set root in the p-th block header, then based on the block height of the p-th request transaction block and the block height of the M-th request transaction block, the third block request range is determined, and a block information synchronization request is sent to the data sending node based on the third block request range.

[0162] Step S613: Update the first state data and update the first block height.

[0163] In this embodiment, the data request node can update the first state data based on the transaction write information of the p-th requested transaction block, and update the first block height based on the block height of the p-th requested transaction block. The process of updating the first state data can be found in [reference needed]. Figure 4 The process of updating the first state data after step S404; the process of updating the first block height can be recorded as LastHeight = block_p.header.Height - 1. Further, step S614 is executed.

[0164] Step S614, p++.

[0165] In this embodiment of the application, the data request node can update the value of p, that is, process the next request transaction block and then execute step S615.

[0166] Step S615: Detect whether there are any unprocessed request transaction blocks among the M request transaction blocks.

[0167] In this embodiment, the data request node can detect whether there are any unprocessed request transaction blocks among the M request transaction blocks. If there are unprocessed request transaction blocks, it returns to step S603; if there are no unprocessed request transaction blocks, it indicates that the block information corresponding to the M request transaction blocks has been processed, and it can wait until new block information is received. Optionally, when there are no unprocessed request transaction blocks, if the data request node detects that there is an unsynchronized block range within the range of blocks to be synchronized, it can obtain a second block request range from the unsynchronized block range, and based on the second block request range, continue to send a block information synchronization request to the data sending node, such as... Figure 4 The relevant description in the document.

[0168] Further, please see Figure 7 , Figure 7 This is a schematic diagram of a signature verification process provided in an embodiment of this application. Figure 7 As shown, this signature verification process is performed by the data sending node and can be used to represent... Figure 6 The specific implementation process of step S609. (Based on...) Figure 4 Taking case ② in step S403 as an example, the signature verification process includes the following steps:

[0169] Step S701: Detect that the p-th request transaction block is either the first or the last request transaction block among the M request transaction blocks.

[0170] In this embodiment, p is initially set to 1. The data request node can detect whether the p-th request transaction block is the first or last request transaction block among M request transaction blocks. For example, it can check whether "p == 1 || p == len(blocks)" is true. If the p-th request transaction block is detected as either the first or last request transaction block among M request transaction blocks, step S702 is executed. If the p-th request transaction block is neither the first nor the last request transaction block among M request transaction blocks, step S703 is executed. Here, len(blocks) represents the number of request transaction blocks corresponding to the request block information set, i.e., M, and "||" represents "or".

[0171] Step S702: Detect whether the target consensus node corresponding to the target node signature of the p-th request transaction block is a data sending node.

[0172] In this embodiment, the data request node can detect whether the target consensus node corresponding to the target node signature of the p-th request transaction block is a data sending node. If the target consensus node corresponding to the target node signature of the p-th request transaction block is a data sending node, then step S705 is executed; if the target consensus node corresponding to the target node signature of the p-th request transaction block is not a data sending node, then step S704 is executed.

[0173] Step S703: Detect whether the target consensus node corresponding to the signature of the target node of the p-th target consensus node is the same as that of the target consensus node of the (p-1)-th request transaction block.

[0174] In this embodiment of the application, if the target consensus node corresponding to the target node signature of the p-th request transaction block is the same as the target consensus node corresponding to the target node signature of the (p-1)-th request transaction block, then step S705 is executed; if the target consensus node corresponding to the target node signature of the p-th request transaction block is different from the target consensus node corresponding to the target node signature of the (p-1)-th request transaction block, then step S704 is executed.

[0175] Step S704: Confirm that the signature verification of the p-th target node has passed.

[0176] In this embodiment of the application, the data request node can determine that the signature verification of the p-th target node has passed, and can then execute... Figure 6 Step S611 is shown in the figure.

[0177] Step S705: Determine that the information of the p-th block is abnormal, and delete the information of the p-th block.

[0178] In this embodiment, the data request node can determine that the p-th block information is abnormal and delete the p-th block information. Optionally, the data request node can determine the third block request range based on the block height of the p-th requested transaction block and the block height of the M-th requested transaction block, and send a block information synchronization request to the data sending node based on the third block request range.

[0179] In this embodiment, a block information synchronization request is sent to the data sending node, and a block data synchronization request is sent to the data sending node; the block information sent by the data sending node based on the block information synchronization request is obtained; the block information includes the block header, transaction read information, transaction write information, and target node signature of the requested transaction block indicated by the block information synchronization request; the block header, transaction read information, transaction write information, and target node signature of the requested transaction block are verified; when the block information of the requested transaction block is verified, the block data sent by the data sending node based on the block data synchronization request is obtained, and the block data is written into the blockchain. Through the above process, the synchronization of transaction blocks can be broken down into a block information synchronization process and a block data synchronization process. The block information synchronization process first synchronizes the block information of the transaction blocks that need to be synchronized. This block information includes the data required to verify a transaction block. Then, the complete block data of the transaction block is continuously synchronized. The block information synchronization process and the block data synchronization process are performed separately and independently. This allows data request nodes to synchronize block information based on the block information synchronization process first. Since the amount of block information is generally small, this improves the block synchronization efficiency of data request nodes. This allows data request nodes to quickly participate in the block consensus and block generation processes in the blockchain system, thereby improving the performance of the blockchain system. Furthermore, because the block information includes the data required to verify a transaction block, when data request nodes join the block consensus and block generation processes in the blockchain system based on the block information, the consistency of the ledger synchronization and the security of the ledger data can be guaranteed. Moreover, the data request node will also synchronize the complete data of the transaction block through the block data synchronization process. This block data synchronization process will not affect the operation of the data request node in the blockchain system, and can ensure the integrity of the ledger data in the data request node.

[0180] Further, please see Figure 8 , Figure 8 This is a flowchart of another blockchain data synchronization method provided in an embodiment of this application. Figure 8 As shown, the blockchain data synchronization process is executed by the data sending node, and includes the following steps:

[0181] Step S801: When a block information synchronization request is received from a data request node, the block header, transaction read information, transaction write information, and target node signature of the requested transaction block indicated by the block information synchronization request are obtained.

[0182] In this embodiment of the application, when the data sending node receives a block information synchronization request for the first block request range, it obtains the block header, transaction read information, transaction write information, and target node signature of the request transaction block corresponding to the first block request range.

[0183] Among them, see Figure 9 , Figure 9 This is a schematic diagram of a block hashing scenario provided in an embodiment of this application. For example... Figure 9 As shown, a transaction block 901 may include a block header 9011 and a block body 9012. The block body 9012 consists of one or more transaction data, such as... Figure 9 The transaction data shown is 1 to 4; each transaction data can correspond to one or more transaction read data and one or more transaction write data. The block generating node that generates transaction block 901 can hash the transaction read data corresponding to each transaction data to obtain the transaction read set root, hash the transaction write data corresponding to each transaction data to obtain the transaction write set root, and hash the transaction read set root and transaction write set root of each transaction data to obtain the transaction read-write set root of the transaction data. Further, the transaction read-write set roots of each transaction data can be hashed to obtain the block read-write set root of transaction block 901, and the block read-write set root is written into the block header 9011.

[0184] Specifically, the data sending node can obtain the block header and target node signature of the requested transaction block indicated by the block information synchronization request. It can then obtain the transaction data included in the requested transaction block, and based on this, retrieve the transaction read data. This transaction read data can be directly identified as the transaction read information of the requested transaction block; alternatively, the transaction read data can be hashed to obtain the root of the corresponding transaction read set, which can then be used to determine the transaction read information of the requested transaction block. Figure 9 The transaction read set root 1 corresponding to transaction data 1, transaction read set root 2 corresponding to transaction data 2, transaction read set root 3 corresponding to transaction data 3, and transaction read set root 4 corresponding to transaction data 4 are shown in the figure. For ease of illustration, Figure 9 The example only illustrates the specific generation process of transaction read / write set root 1 for transaction data 1. Transaction write data is obtained from the transaction data and converted into transaction write information. When determining the transaction read set root as transaction read information, since transaction read data itself represents the operation of a smart contract reading data, not information written to a database, meaning it does not affect the data in the blockchain, the transaction read set root can be directly determined as transaction read information. This significantly reduces the amount of block information data, thereby increasing the transmission rate of block information.

[0185] The number of requested transaction blocks is M, where M is a positive integer. When the data sending node obtains the signature of the target node indicated in the block information synchronization request, it corresponds to... Figure 4 In step S403, case ①, the data sending node can determine the node signatures included in the k-th request transaction block as the target node signature for the k-th request transaction block, where k is a positive integer less than or equal to M. Corresponding to... Figure 4 In step S403, case ②, the data sending node can obtain the target node signature corresponding to the (k+1)th request transaction block, and from the node signatures included in the kth request transaction block, obtain a node signature that is different from the target node signature corresponding to the (k+1)th request transaction block, and use it as the target node signature of the kth request transaction block. Corresponding to... Figure 4 In step S403, case ③, the data sending node can determine the number of unit nodes based on M and the number of consensus-passing nodes. This number of unit nodes is greater than the number of consensus-passing nodes / M. Based on the number of unit nodes, the target node signature of the k-th request transaction block is obtained from the node signatures included in the k-th request transaction block. Here, the number of unit nodes refers to the number of node signatures required to obtain from a request transaction block. Optionally, in this case, the target node signatures of different request transaction blocks may be the same. In this case, when obtaining the target node signatures corresponding to the M request transaction blocks respectively, deduplication processing can be performed on the target node signatures corresponding to the M request transaction blocks to obtain deduplicated node signatures. If the number of deduplicated node signatures is less than the number of consensus-passing nodes, then based on the number of deduplicated node signatures and the number of consensus-passing nodes, a new target node signature is added to the target node signatures corresponding to the M request transaction blocks respectively, based on the M request transaction blocks, to obtain the final target node signatures of each request transaction block.

[0186] Specifically, when converting transaction write data into transaction write information, the data sending node can directly identify the transaction write data as the transaction write information. Alternatively, the data sending node can obtain the transaction key data included in the transaction write data of the k-th requested transaction block, and obtain the transaction key data from the transaction write data corresponding to the first to the (k-1)-th requested transaction blocks respectively; k is a positive integer less than or equal to M; the block height of the k-th requested transaction block is less than the block height of the (k-1)-th requested transaction block. If the first to the (k-1)-th transaction key data includes the k-th transaction key data, then the transaction write data of the k-th requested transaction block is hashed to obtain the transaction write information of the k-th requested transaction block; if the first to the (k-1)-th transaction key data does not include the k-th transaction key data, then the transaction write data of the k-th requested transaction block is identified as the transaction write information of the k-th requested transaction block. Since the transaction value data corresponding to the same transaction key data in a transaction block with a larger block height will overwrite the transaction value data corresponding to the same transaction key data in a transaction block with a smaller block height, processing can be carried out sequentially from the Mth requesting transaction block to the first requesting transaction block, which can improve processing efficiency and reduce the amount of block information data.

[0187] For example, see Figure 10 , Figure 10 This is an example diagram of a read / write set for a transaction provided in an embodiment of this application. For example... Figure 10As shown, assume there are two smart contracts. Smart contract 1 is used to query the information of the student with the highest score in the last exam and update it with the information of the student with the highest score in the current exam. Smart contract 2 is used to query the amount of digital asset data owned by a business object and update it with the amount of digital asset data after the business object updates its digital assets. Taking transaction block 1001 and transaction block 1002 as examples, transaction block 1001 is a transaction block with block height "100" and includes transaction data 1 (denoted as Tx1) and transaction data 2 (denoted as Tx2). Tx1 calls smart contract 1 to generate transaction read / write data 1011 (including transaction read set 1 and transaction write set 1), and Tx2 calls smart contract 2 to generate transaction read / write data 1012 (including transaction read set 2 and transaction write set 2). Transaction block 1002 is a transaction block with block height "101", including transaction data 3 (denoted as Tx3) and transaction data 4 (denoted as Tx4). Tx3 calls smart contract 1 to generate transaction read / write data 1021 (including transaction read set 3 and transaction write set 3), and Tx4 calls smart contract 2 to generate transaction read / write data 1022 (including transaction read set 4 and transaction write set 4). Each transaction read set consists of one or more transaction read data, and each transaction write set consists of one or more transaction write data. For example, transaction write set 3 includes transaction write data "Name: Li Si", transaction write data "Age: 10", transaction write data "Class: 1", and transaction write data "Score: 99". The transaction write data "Score: 99" in this transaction write set is the same as the transaction read data "Score: 99" in the transaction read set 3 to be replaced, which can be simplified as follows: Figure 10 The transaction write set 3 is shown in the diagram. Each transaction write data may include transaction key data and transaction value data. For example, in transaction write set 4, the transaction write data "Zhao Liu: 50000" includes the transaction key data "Zhao Liu" and the transaction value data "50000". Each transaction read data may include transaction key data and transaction value data. For example, in transaction read set 4, the transaction read data "Zhao Liu: 20000" includes the transaction key data "Zhao Liu" and the transaction value data "20000".

[0188] Furthermore, taking transaction blocks 1001 and 1002 as examples, see... Figure 11 , Figure 11 This is an example diagram of block hashing provided in an embodiment of this application. For example... Figure 11As shown, when generating transaction read information and transaction write information for transaction blocks 1101 (corresponding to transaction block 1001) and 1102 (corresponding to transaction block 1002), the data sending node can obtain the transaction read data of transaction data 3 in transaction block 1102, and perform hash processing on the transaction read data of Tx3 to obtain the transaction read set hash tree of transaction data 3, the root of which is the transaction read set root; obtain the transaction write data of transaction data 3 in transaction block 1102, and perform hash processing on the transaction write data of Tx3 to obtain the transaction write set hash tree of transaction data 3, the root of which is the transaction write set root of transaction data 3; similarly, the transaction read set hash tree and transaction write set hash tree of transaction data 4 can be obtained, the root of which is the transaction read set root of transaction data 4, and the root of which is the transaction write set root of transaction data 4. Specifically, the data sending node can determine the transaction read set root of transaction data 3 and the transaction read set root of transaction data 4 as the transaction read information corresponding to transaction block 1102. Since there are no transaction blocks that require block information generation before transaction block 1102, the transaction write data corresponding to transaction data 3 in transaction block 1102 (such as...) can be directly used. Figure 11 The “Name: Li Si”, “Age: 10”, and “Class: 1” shown in the figure correspond to the transaction write data (such as) of transaction data 4. Figure 11 The "Zhao Liu: 50000" shown in the figure is identified as the transaction write information corresponding to transaction block 1102.

[0189] Similarly, the transaction read set hash tree and transaction write set hash tree for transaction data 1 can be obtained, as can the transaction read set hash tree and transaction write set hash tree for transaction data 2. The data sending node can determine the transaction read set root in the transaction read set hash tree of transaction data 1 and the transaction read set root in the transaction read set hash tree of transaction data 2 as the transaction read information corresponding to transaction block 1101. Among them, in the transaction write data of transaction data 1, the transaction key data "name, age, class" already exists in the transaction write data of transaction data 3. Therefore, the hash value of the first transaction key data corresponding to transaction data 1 (such as transaction write hash 12 and transaction write hash 3 of transaction data 1) and the transaction write data to which the second transaction key data belongs can be obtained to form the transaction sub-write information of transaction data 1. The first transaction key data refers to the transaction key data that appeared in the transaction write data of the (k+1)th requested transaction block (here referring to transaction block 1102), or the transaction key data that appeared in the transaction write data corresponding to the (k+1)th to the Mth requested transaction blocks respectively. The second transaction key data refers to the transaction key data that did not appear in the transaction write data of the (k+1)th requested transaction block. Similarly, the transaction sub-write information of transaction data 2 can be obtained. The data sending node can determine the transaction write information corresponding to transaction block 1101 by combining the transaction sub-write information of transaction data 1 and transaction sub-write information of transaction data 2.

[0190] In other words, when multiple transaction data exist within a request transaction block, the data sending node can obtain the transaction sub-write information corresponding to each transaction data, and combine the transaction sub-write information corresponding to each transaction data into the transaction write information corresponding to the request transaction block. Optionally, if multiple consecutive transaction write data within a transaction data contain transaction key data that is the first transaction key data, the Merkle root (e.g., the merged result of these multiple transaction write data) can be directly obtained. Figure 11 The transaction write hash of transaction data 1 in the example is shown in Figure 12. By hashing the transaction read data and transaction write data, the amount of block information can be reduced, and the transmission efficiency of block information can be improved.

[0191] Step S802: The block information of the requested transaction block is composed of the block header, transaction read information, transaction write information and target node signature. The block information is then sent to the data request node so that the data request node can verify the block information of the requested transaction block.

[0192] In this embodiment, the data sending node can assemble the block information of the requested transaction block from the block header, transaction read information, transaction write information, and the target node's signature, and send the block information to the data requesting node so that the data requesting node can execute the request. Figure 4 The steps shown.

[0193] Step S803: When a block data synchronization request is received from a data request node, the block data of the requested transaction block indicated by the block data synchronization request is sent to the data request node so that the data request node writes the block data into the blockchain when the block information of the requested transaction block is verified.

[0194] In this embodiment of the application, the block data refers to the complete data of the request transaction block.

[0195] In simple terms, the data sending node returns the same data to the data requesting node as it receives the request, thus splitting the process of synchronizing block information and block data.

[0196] For details, please refer to Figure 12 , Figure 12 This is a schematic diagram illustrating another specific process for blockchain data synchronization provided in an embodiment of this application. For example... Figure 12 As shown, the blockchain data synchronization process is executed by the data sending node, and includes the following steps:

[0197] Step S1201: Obtain the block request range and obtain the second block height.

[0198] In this embodiment, the data sending node can obtain the block request range ([startHeight, endHeight]) indicated by the block information synchronization request and obtain the second block height (h). Here, the block request range is taken as an example of the first block request range, and the second block height refers to the maximum block height of the transaction blocks included by the data sending node. Specifically, the block request range refers to the height range from the first request height (startHeight) to the second request height (endHeight), where the first request height is the minimum block height within the block request range, and the second request height is the maximum block height within the block request range.

[0199] Step S1202: Detect whether the height of the second block is less than the second request height in the block request range.

[0200] In the embodiments of the present application, the data sending node may detect whether the second block height is less than the second requested height in the block request range, that is, detect whether h < endHeight is true. If the second block height is less than the second requested height, it indicates that the data sending node lacks the data requested by the partial block information synchronization request, and the data sending node may send an information synchronization exception message to the data requesting node, so that the data requesting node may request the block information corresponding to the block request range from other blockchain nodes, that is, send a block information synchronization request for the block request range to other blockchain nodes; if the second block height is greater than or equal to the second requested height, step S1203 is executed.

[0201] Step S1203: Initialize the to-be-parsed block height i, and generate an initial block information set.

[0202] In the embodiments of the present application, the data sending node may initialize the to-be-parsed block height i, which may be denoted as i = endHeight, and generate the initial block information set blocks'. Alternatively, k may also be initialized, which is denoted as k = M.

[0203] Step S1204: Acquire the block header, transaction read data and transaction write data corresponding to the to-be-parsed block height i.

[0204] In the embodiments of the present application, the block header, transaction read data Ri and transaction write data Wi corresponding to the to-be-parsed block height i are acquired.

[0205] Step S1205: Acquire the transaction read information corresponding to the transaction read data.

[0206] In the embodiments of the present application, the data sending node may initialize the to-be-parsed transaction position j based on the quantity of transaction data included in the requested transaction block i corresponding to the to-be-parsed block height i, which may be denoted as j = len(bi.txs), where bi refers to the requested transaction block corresponding to the to-be-parsed block height i, txs refers to transaction data, bi.txs refers to the transaction data included in the requested transaction block i corresponding to the to-be-parsed block height i, and len() is used for counting the quantity; acquire the transaction read set root of the transaction data included in the requested transaction block i corresponding to the to-be-parsed block height i based on the to-be-parsed transaction position, and determine the transaction read set root of the transaction data included in the requested transaction block i as the transaction read information corresponding to the requested transaction block i. For details, reference may be made to Figure 8 the relevant description in step S801.

[0207] Step S1206: Acquire the transaction write information corresponding to the transaction write data.

[0208] In the embodiments of the present application, reference may be made to Figure 8The relevant description in step S801.

[0209] Step S1207: Obtain the target node signature of the i-th transaction block from the additional data.

[0210] In this embodiment, the data sending node can obtain the target node signature of the i-th transaction block from the additional data (AdditionData) of the requested transaction block i. For details, please refer to... Figure 8 The relevant description in step S801. At this time, the data sending node can compose the block information corresponding to the requested transaction block i, the block header, transaction write information, transaction read information, and target node signature.

[0211] Step S1208, i--.

[0212] In this embodiment of the application, the data sending node can update the height i of the block to be parsed in order to process the next request transaction block and further execute step S1209.

[0213] Step S1209: Detect whether the height i of the block to be parsed is greater than or equal to the first request height in the block request range.

[0214] In this embodiment of the application, if the height i of the block to be parsed is detected to be greater than or equal to the first request height in the block request range, it indicates that there is an unprocessed transaction block in the request transaction block indicated by the block request range, and the process can return to step S1204; if the height i of the block to be parsed is detected to be less than the first request height in the block request range, it indicates that all block information corresponding to the block request range has been obtained, and step S1210 is executed.

[0215] Step S1210: Send the block information corresponding to the requested transaction block within the block request range to the data request node.

[0216] In this embodiment of the application, the data sending node can send the block information corresponding to the requested transaction block within the block request range to the data request node.

[0217] Furthermore, the specific implementation process of steps S1205 to S1206 can be found in [reference needed]. Figure 13 , Figure 13 This is a schematic diagram of a transaction read / write set processing flow provided in an embodiment of this application. For example... Figure 13 As shown, the read / write set processing of this transaction is executed by the data sending node, and the read / write set processing of this transaction includes the following steps:

[0218] Step S1301: Obtain the number of transactions included in the requested transaction block, and initialize the position j of the transaction to be parsed based on the number of transactions.

[0219] In this embodiment of the application, the data sending node can obtain the number of transactions included in the requested transaction block i, and initialize the transaction position j to be parsed based on the number of transactions.

[0220] Step S1302: Obtain the transaction write set and transaction read set of the j-th transaction data.

[0221] In this embodiment of the application, the data sending node can obtain the transaction read set Rij and the transaction write set Wij of the j-th transaction data, wherein the transaction read set Rij may include one or more transaction read data, and the transaction write set Wij may include one or more transaction write data.

[0222] Step S1303: Obtain the root of the transaction read set corresponding to the transaction read set.

[0223] In this embodiment of the application, the transaction read set root corresponding to the transaction read set Rij can be denoted as RSetRoot[j], which represents the transaction read set root corresponding to the j-th transaction data and is a Merkle root.

[0224] Step S1304: Traverse the transaction key data in the transaction write set, and combine the transaction write hash corresponding to the first transaction key data and the transaction write data corresponding to the second transaction key data in the transaction write set to form the transaction write information corresponding to the transaction write set.

[0225] In this embodiment, the data sending node can traverse the transaction key data in the transaction write set Wij. For transaction key data that has already appeared (i.e., the first transaction key data), the transaction write hash corresponding to the first transaction key data is obtained. Furthermore, the transaction write hash corresponding to the first transaction key data and the transaction write data corresponding to the second transaction key data can be combined to form the transaction sub-write information (ReturnWj) corresponding to the j-th transaction data.

[0226] Optionally, if multiple first transaction key data exist, they can be represented as multiple first transaction key data in the form of a Merkle tree. Specifically, the data sending node can hash the transaction write data corresponding to each of the multiple first transaction key data to obtain the total hash value, which can be denoted as the convergent hash root (e.g., ...). Figure 11(Transaction write hash 12) of transaction data 1 in the first transaction key data. At this time, the data sending node can combine the transaction write data corresponding to the second transaction key data, the obtained converged hash root, and the transaction write hash corresponding to the single transaction key data in the first transaction key data to form the transaction sub-write information corresponding to the j-th transaction data. Here, the single transaction key data refers to the first transaction key data in the first transaction key data other than the first transaction key data corresponding to the converged hash root.

[0227] Optional, see also Figure 8 The relevant description in step S801.

[0228] Step S1305, j--.

[0229] In this embodiment of the application, the transaction position j to be parsed is updated, and then step S1306 is executed.

[0230] Step S1306: Detect whether there is unresolved transaction data in the requested transaction block.

[0231] In this embodiment, the data sending node can detect whether there is unparsed transaction data in the requested transaction block, that is, detect whether j>0 is true. If unparsed transaction data is detected in the requested transaction block i, then step S1302 is executed; if no unparsed transaction data is detected in the requested transaction block i, then step S1307 is executed.

[0232] Step S1307: The block information of the requested transaction block is composed of the block header corresponding to the requested transaction block, the target node signature, and the transaction read set root and transaction write information of the transaction data included in the requested transaction block.

[0233] In this embodiment, the data sending node can form the transaction read information corresponding to the requested transaction block i by using the transaction read set root of the transaction data included in the requested transaction block i; and form the transaction write information corresponding to the requested transaction block i by using the transaction sub-write information of the transaction data included in the requested transaction block i; based on Figure 12 In step S1207, the target node signature of the requested transaction block i is obtained. The data sending node can assemble the block information of the requested transaction block i from the block header, target node signature, transaction read information, and transaction write information. Further, the following can be executed: Figure 12 Step S1208 in the process.

[0234] Among them, see Figure 14 , Figure 14 This is an example diagram illustrating the interaction in a blockchain data synchronization scenario provided in an embodiment of this application. For example... Figure 14As shown, assuming N is 2, the data request node is blockchain node 1, and the N data sending nodes include blockchain node 2 and blockchain node 3. Specifically, blockchain node 2 and blockchain node 3 can broadcast a second block height, which is the maximum block height of the transaction blocks included in the corresponding blockchain node. When blockchain node 1 receives the second block heights sent by blockchain node 2 and blockchain node 3, it can determine the maximum synchronization height from the multiple second block heights and obtain the first block height. If the first block height is less than the maximum synchronization height, the range of blocks to be synchronized is determined based on the first block height and the maximum synchronization height.

[0235] Furthermore, blockchain node 1 can determine the first block request range corresponding to blockchain node 2 and blockchain node 3 respectively within the block height to be synchronized; based on the first block request range, step S21 is executed to request block information synchronization, that is, sending a block information synchronization request to blockchain node 2 for the first block request range corresponding to blockchain node 2, and sending a block information synchronization request to blockchain node 3 for the first block request range corresponding to blockchain node 3. Simultaneously, step S31 can be executed to request block data synchronization, that is, sending a block data synchronization request to blockchain node 2 for the first block request range corresponding to blockchain node 2 (assumed to be [1, 25]), and sending a block data synchronization request to blockchain node 3 for the first block request range corresponding to blockchain node 3 (assumed to be [26, 50]). Since the amount of block data is much larger than the amount of block information, generally, for a block request range, blockchain node 1 will receive the block information first, then the block data. Of course, if the block data is received first, it can also be synchronized through... Figure 4 The relevant description in step S404 describes the storage of block data.

[0236] by Figure 14For example, blockchain node 1 first receives block information. Blockchain node 1 can execute step S22 to verify the received block information and update its local state database (i.e., update the first state data). During the execution of step S22, blockchain node 1 receives block data. At this point, blockchain node 1 can continue executing step S22 while simultaneously executing step S32 to verify the received block data and write it to its local transaction ledger. During the execution of step S32, blockchain node 1 completes step S22. At this point, blockchain node 1 can continue executing step S22, obtain the second block request range, and execute step S23 to request block information synchronization, that is, to continue synchronizing the block information of subsequent transaction blocks. Similarly, upon completion of step S32, step S33 is executed to request block data synchronization, that is, to continue synchronizing the block data of subsequent transaction blocks.

[0237] like Figure 14 As shown, this application splits the block synchronization process into two independent processes: the block information synchronization process and the block data synchronization process. This allows data request nodes to quickly join the network based on the block information synchronization process, which involves a smaller amount of data, and to ensure the data integrity of the blockchain by slowly executing the block data synchronization process.

[0238] Further, please see Figure 15 , Figure 15 This is a schematic diagram of a blockchain data synchronization device provided in an embodiment of this application. The blockchain data synchronization device can be a computer program (including program code, etc.) running on a computer device; for example, the blockchain data synchronization device can be an application software. This device can be used to execute the corresponding steps in the method provided in the embodiments of this application. Figure 15 As shown, the blockchain data synchronization device 1500 can be used for Figure 4 Specifically, the computer device in the corresponding embodiment may include: a request sending module 11, an information acquisition module 12, an information verification module 13, and a data synchronization module 14.

[0239] Request sending module 11 is used to send block information synchronization requests to data sending nodes and block data synchronization requests to data sending nodes;

[0240] The information acquisition module 12 is used to acquire the block information sent by the data sending node based on the block information synchronization request; the block information includes the block header, transaction read information, transaction write information and target node signature of the requested transaction block indicated by the block information synchronization request;

[0241] The information verification module 13 is used to verify the block header, transaction read information, transaction write information, and target node signature of the requested transaction block;

[0242] The data synchronization module 14 is used to obtain the block data sent by the data sending node based on the block data synchronization request when the block information of the requested transaction block is verified, and write the block data into the blockchain.

[0243] The number of data sending nodes is N; N is a positive integer.

[0244] The request sending module 11 can be used for:

[0245] Get the maximum synchronization height and the first block height, and get the number of data sending nodes N; the first block height refers to the maximum block height of the first transaction block included by the data request node;

[0246] The number of blocks to be synchronized for the data request node is determined based on the maximum synchronization height and the height of the first block.

[0247] Based on the number of blocks to be synchronized and N, determine the first block request range corresponding to each of the N data sending nodes;

[0248] Based on the first block request range corresponding to each of the N data sending nodes, block information synchronization requests are sent to each of the N data sending nodes, and block data synchronization requests are sent to each of the N data sending nodes.

[0249] The information verification module 13 can be used for:

[0250] Obtain the transaction read set root from the transaction read information, generate the request write set root based on the transaction write information, and combine the request write set root with the transaction read set root to form the request read write set root;

[0251] Obtain the block read / write set root of the requested transaction block from the block header;

[0252] If the root of the requested read / write set is the same as the root of the block read / write set, and the signature verification of the target node is successful, then the block information of the requested transaction block is verified.

[0253] The information verification module 13 can be used for:

[0254] The block header, transaction read information, and transaction write information of the requested transaction block are verified to obtain the information verification results;

[0255] Obtain the target consensus node corresponding to the target node signature of the requested transaction block, verify the target node signature based on the target consensus node, and obtain the signature verification result;

[0256] If the information verification result is "information verification passed" and the signature verification result is "signature verification passed", then it is determined that the block information verification of the requested transaction block has passed.

[0257] If the information verification result is a failure result, or the signature verification result is a failure result, then it is determined that the block information verification for the requested transaction block has failed.

[0258] The number of requested transaction blocks is M, where M is a positive integer;

[0259] When verifying the signature of the target node based on the target consensus node and obtaining the signature verification result, the information verification module 13 can be used for:

[0260] If the p-th request transaction block is the first or last request transaction block among M request transaction blocks, then if the target consensus node corresponding to the target node signature of the p-th request transaction block is a data sending node, the signature verification failure result is determined as the signature verification result of the p-th request transaction block; if the target consensus node corresponding to the target node signature of the p-th request transaction block is not a data sending node, the signature verification success result is determined as the signature verification result of the p-th request transaction block; p is a positive integer less than or equal to M;

[0261] If the p-th request transaction block is neither the first nor the last of the M request transaction blocks, then if the target consensus node corresponding to the target node signature of the p-th request transaction block is the same as the target consensus node corresponding to the target node signature of the (p-1)-th request transaction block, the signature verification failure result is determined as the signature verification result of the p-th request transaction block; if the p-th target consensus node is different from the (p-1)-th target consensus node, the signature verification success result is determined as the signature verification result of the p-th request transaction block.

[0262] The number of requested transaction blocks is M, where M is a positive integer;

[0263] When verifying the signature of the target node based on the target consensus node and obtaining the signature verification result, the information verification module 13 can be used for:

[0264] Deduplication is performed on the target consensus nodes corresponding to the M request transaction blocks to obtain the deduplicated nodes;

[0265] Get the number of first nodes after deduplication, and get the number of nodes that have passed consensus.

[0266] If the number of first nodes is less than the number of nodes that have passed consensus, then the signature verification failure result is determined as the signature verification result of M request transaction blocks;

[0267] If the number of first nodes is greater than or equal to the number of nodes that have passed consensus, then the signature verification result is determined as the signature verification result of M request transaction blocks.

[0268] The device 1500 also includes:

[0269] The information lookup module 15 is used to look up the block information corresponding to the block data when it receives block data sent by the data sending node based on the block data synchronization request.

[0270] The data caching module 16 is used to cache block data if no block information is found or the block information verification fails.

[0271] When the block information of the requested transaction block is verified, and the data synchronization module 14 obtains the block data sent by the data sending node based on the block data synchronization request, the data synchronization module 14 can be used for:

[0272] When the block information of the requested transaction block is verified, the cached block data is retrieved.

[0273] The number of requested transaction blocks is M, where M is a positive integer; the device 1500 also includes:

[0274] Write processing module 17 is used to obtain the transaction write information of the p-th requested transaction block; p is a positive integer less than or equal to M;

[0275] The write processing module 17 is also used to update the first state data according to the transaction write information of the p-th request transaction block if the transaction write information of the p-th request transaction block is data of the first type; the first type refers to the data type of the transaction write data.

[0276] The write processing module 17 is also used to obtain the transaction write information of the (p+1)th request transaction block if the transaction write information of the pth request transaction block is data of the second type; the second type refers to the hash type.

[0277] When the block information of the requested transaction block is verified, the device 1500 further includes:

[0278] The range determination module 18 is used to obtain the second block request range from the unsynchronized block range if there is an unsynchronized block range in the range of blocks to be synchronized; the range of blocks to be synchronized refers to the block height range of the transaction blocks that the data request node is missing.

[0279] The continued synchronization module 19 is used to continue sending block information synchronization requests to the data sending node based on the second block request range, and to store the second block request range;

[0280] The continued synchronization module 19 is also used to continue sending block data synchronization requests to the data sending node based on the second block request range when block data is written into the blockchain.

[0281] The device 1500 also includes:

[0282] The function update module 20 is used to obtain the first block request range corresponding to the block information synchronization request and the block data synchronization request, and to obtain the functional block range associated with the block query function; the functional block range refers to the block height range of the transaction blocks targeted by the block query function.

[0283] The function update module 20 is also used to update the function block range based on the first block request range when writing block data into the blockchain; the updated function block range includes the first block request range.

[0284] This application provides a blockchain data synchronization device that can operate in a data request node. The device sends a block information synchronization request to a data sending node and a block data synchronization request to the data sending node. It acquires the block information sent by the data sending node based on the block information synchronization request. The block information includes the block header, transaction read information, transaction write information, and target node signature of the requested transaction block indicated by the block information synchronization request. The device verifies the block header, transaction read information, transaction write information, and target node signature of the requested transaction block. When the block information of the requested transaction block is verified, the device acquires the block data sent by the data sending node based on the block data synchronization request and writes the block data into the blockchain. Through the above process, the synchronization of transaction blocks can be broken down into a block information synchronization process and a block data synchronization process. The block information synchronization process first synchronizes the block information of the transaction blocks that need to be synchronized. This block information includes the data required to verify a transaction block. Then, the complete block data of the transaction block is continuously synchronized. The block information synchronization process and the block data synchronization process are performed separately and independently. This allows data request nodes to synchronize block information based on the block information synchronization process first. Since the amount of block information is generally small, this improves the block synchronization efficiency of data request nodes. This allows data request nodes to quickly participate in the block consensus and block generation processes in the blockchain system, thereby improving the performance of the blockchain system. Furthermore, because the block information includes the data required to verify a transaction block, when data request nodes join the block consensus and block generation processes in the blockchain system based on the block information, the consistency of the ledger synchronization and the security of the ledger data can be guaranteed. Moreover, the data request node will also synchronize the complete data of the transaction block through the block data synchronization process. This block data synchronization process will not affect the operation of the data request node in the blockchain system, and can ensure the integrity of the ledger data in the data request node.

[0285] Further, please see Figure 16 , Figure 16 This is a schematic diagram of another blockchain data synchronization device provided in an embodiment of this application. The blockchain data synchronization device can be a computer program (including program code, etc.) running on a computer device; for example, the blockchain data synchronization device can be an application software. This device can be used to execute the corresponding steps in the method provided in the embodiments of this application. Figure 16 As shown, the blockchain data synchronization device 1600 can be used for Figure 8 Specifically, the computer device in the corresponding embodiment may include: a data acquisition module 31, an information processing module 32, and a data transmission module 33.

[0286] The data acquisition module 31 is used to acquire the block header, transaction read information, transaction write information and target node signature of the requested transaction block indicated by the block information synchronization request when it receives a block information synchronization request sent by a data request node.

[0287] The information processing module 32 is used to assemble the block header, transaction read information, transaction write information and target node signature of the requested transaction block into block information of the requested transaction block, and send the block information to the data request node so that the data request node can verify the block information of the requested transaction block.

[0288] The data sending module 33 is used to send the block data of the requested transaction block indicated by the block data synchronization request to the data request node when it receives the block data synchronization request sent by the data request node, so that the data request node can write the block data into the blockchain when the block information of the requested transaction block is verified.

[0289] Specifically, when obtaining the block header, transaction read information, transaction write information, and target node signature of the requested transaction block indicated by the block information synchronization request, the data acquisition module 31 can be used for:

[0290] Obtain the block header and target node signature of the requested transaction block indicated by the block information synchronization request;

[0291] Obtain the transaction data included in the requested transaction block, obtain the transaction read data based on the transaction data, perform hash processing on the transaction read data to obtain the transaction read set root corresponding to the transaction data, and determine the transaction read set root as the transaction read information of the requested transaction block;

[0292] Obtain transaction write data from the transaction data, and convert the transaction write data into transaction write information.

[0293] The number of requested transaction blocks is M, where M is a positive integer;

[0294] When converting transaction write data into transaction write information, the data acquisition module 31 can be used for:

[0295] Get the transaction key data included in the transaction write data of the k-th requested transaction block, and get the transaction key data in the transaction write data corresponding to the first to the (k-1)-th requested transaction blocks respectively; k is a positive integer less than or equal to M; the block height of the k-th requested transaction block is less than the block height of the (k-1)-th requested transaction block.

[0296] If the first transaction key data includes the (k-1)th transaction key data, then the transaction write data of the kth request transaction block is hashed to obtain the transaction write information of the kth request transaction block.

[0297] If the first transaction key data is included in the (k-1)th transaction key data but not the kth transaction key data, then the transaction write data of the kth requested transaction block will be determined as the transaction write information of the kth requested transaction block.

[0298] This application provides a blockchain data synchronization device that can operate in a data request node.

[0299] See Figure 17 , Figure 17 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 17 As shown, the computer device in this embodiment may include one or more processors 1701, a memory 1702, and an input / output interface 1703. The processor 1701, memory 1702, and input / output interface 1703 are connected via a bus 1704. The memory 1702 stores a computer program, which includes program instructions. The input / output interface 1703 receives and outputs data, such as for data interaction between various blockchain nodes. The processor 1701 executes the program instructions stored in the memory 1702.

[0300] When the processor 1701 is located in the data request node, it can perform the following operations:

[0301] Send a block information synchronization request to the data sending node, and send a block data synchronization request to the data sending node;

[0302] The data sending node obtains the block information sent by the block information synchronization request; the block information includes the block header, transaction read information, transaction write information and target node signature of the requested transaction block indicated by the block information synchronization request;

[0303] Verify the block header, transaction read information, transaction write information, and target node signature of the requested transaction block;

[0304] When the block information of the requested transaction block is verified, the data sending node obtains the block data sent based on the block data and writes the block data into the blockchain.

[0305] When the processor 1701 is located at the data transmission node, it can perform the following operations:

[0306] When a block information synchronization request is received from a data request node, the block header, transaction read information, transaction write information, and target node signature of the requested transaction block indicated in the block information synchronization request are obtained.

[0307] The block information of the requested transaction block is composed of the block header, transaction read information, transaction write information, and target node signature. The block information is then sent to the data request node so that the data request node can verify the block information of the requested transaction block.

[0308] When a block data synchronization request is received from a data request node, the block data of the requested transaction block indicated in the block data synchronization request is sent to the data request node so that the data request node can write the block data into the blockchain when the block information of the requested transaction block is verified.

[0309] In some feasible implementations, the processor 1701 may be a central processing unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0310] The memory 1702 may include read-only memory and random access memory, and provides instructions and data to the processor 1701 and input / output interface 1703. A portion of the memory 1702 may also include non-volatile random access memory. For example, the memory 1702 may also store device type information.

[0311] In practice, the computer device can perform actions such as these through its built-in functional modules. Figure 4 or Figure 6 For details on the implementation methods provided for each step, please refer to [the relevant documentation / document / etc.]. Figure 4 or Figure 6 The implementation methods provided for each step are not elaborated here.

[0312] This application provides a computer device including a processor, an input / output interface, and a memory. The processor retrieves a computer program from the memory and executes it. Figure 4 or Figure 6Each step of the method shown performs blockchain data synchronization operations. This embodiment of the application implements sending a block information synchronization request to a data sending node; receiving the block information sent by the data sending node based on the block information synchronization request; the block information includes the block header, transaction read information, transaction write information, and target node signature of the requested transaction block indicated by the block information synchronization request; verifying the block header, transaction read information, transaction write information, and target node signature of the requested transaction block; and, upon successful verification of the block information of the requested transaction block, receiving the block data sent by the data sending node based on the block data synchronization request and writing the block data into the blockchain. Through the above process, the synchronization of transaction blocks can be broken down into a block information synchronization process and a block data synchronization process. The block information synchronization process first synchronizes the block information of the transaction blocks that need to be synchronized. This block information includes the data required to verify a transaction block. Then, the complete block data of the transaction block is continuously synchronized. The block information synchronization process and the block data synchronization process are performed separately and independently. This allows data request nodes to synchronize block information based on the block information synchronization process first. Since the amount of block information is generally small, this improves the block synchronization efficiency of data request nodes. This allows data request nodes to quickly participate in the block consensus and block generation processes in the blockchain system, thereby improving the performance of the blockchain system. Furthermore, because the block information includes the data required to verify a transaction block, when data request nodes join the block consensus and block generation processes in the blockchain system based on the block information, the consistency of the ledger synchronization and the security of the ledger data can be guaranteed. Moreover, the data request node will also synchronize the complete data of the transaction block through the block data synchronization process. This block data synchronization process will not affect the operation of the data request node in the blockchain system, and can ensure the integrity of the ledger data in the data request node.

[0313] This application also provides a computer-readable storage medium storing a computer program adapted to be loaded and executed by a processor. Figure 4 or Figure 6 For details on the blockchain data synchronization methods provided in each step, please refer to [the relevant documentation / document / etc.]. Figure 4 or Figure 6The implementation methods provided for each step are not repeated here. Furthermore, the beneficial effects of using the same method are also not repeated. For technical details not disclosed in the computer-readable storage medium embodiments involved in this application, please refer to the description of the method embodiments of this application. As an example, a computer program may be deployed to execute on a single computer device, or on multiple computer devices located in one location, or on multiple computer devices distributed across multiple locations and interconnected via a communication network.

[0314] The computer-readable storage medium can be the blockchain data synchronization device provided in any of the foregoing embodiments or the internal storage unit of the computer device, such as the hard drive or memory of the computer device. The computer-readable storage medium can also be an external storage device of the computer device, such as a plug-in hard drive, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device. Furthermore, the computer-readable storage medium can include both internal storage units and external storage devices of the computer device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

[0315] This application also provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform... Figure 4 or Figure 6The method provided among the various optional approaches breaks down the transaction block synchronization process into a block information synchronization process and a block data synchronization process. The block information synchronization process first synchronizes the block information of the transaction blocks to be synchronized, which includes the data required to verify a transaction block. Then, it continuously synchronizes the complete block data of the transaction block. The block information synchronization process and the block data synchronization process are performed independently, allowing data request nodes to synchronize block information based on the block information synchronization process first. Since the amount of block information is generally small, this improves the block synchronization efficiency of data request nodes, enabling them to quickly participate in the block consensus and block generation processes within the blockchain system, thereby improving the performance of the blockchain system. Furthermore, because the block information includes the data required to verify a transaction block, it also ensures the consistency and security of the ledger data when data request nodes join the block consensus and block generation processes based on the block information. Moreover, the data request node will also synchronize the complete data of the transaction block through the block data synchronization process. This block data synchronization process will not affect the operation of the data request node in the blockchain system, and can ensure the integrity of the ledger data in the data request node.

[0316] The terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the term "comprising," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, apparatus, product, or device that includes a series of steps or units is not limited to the listed steps or modules, but may optionally include steps or modules not listed, or may optionally include other step units inherent to these processes, methods, apparatuses, products, or devices.

[0317] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0318] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been generally described in terms of functionality. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0319] The methods and related apparatus provided in this application are described with reference to the method flowcharts and / or structural diagrams provided in this application. Specifically, each block of the method flowchart and / or structural diagram, as well as combinations of blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable blockchain data synchronization device to create a machine, such that the instructions executed by the processor of the computer or other programmable blockchain data synchronization device generate instructions for implementing the process... Figure 1 A schematic diagram of one or more processes and / or structures. Figure 1 The means specifies the functions specified in one or more boxes. These computer program instructions may also be stored in a computer-readable storage medium capable of directing a computer or other programmable blockchain data synchronization device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in the process. Figure 1 A schematic diagram of one or more processes and / or structures. Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable blockchain data synchronization device, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable device for implementing the process. Figure 1 A process or multiple processes and / or structures illustrate the steps of the functions specified in one or more boxes.

[0320] The steps in the method of this application embodiment can be adjusted, combined, or deleted according to actual needs.

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

[0322] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A blockchain data synchronization method, characterized in that, The method is executed by the data request node, and the method includes: Send a block information synchronization request to the data sending node, and send a block data synchronization request to the data sending node; Obtain the block information sent by the data sending node based on the block information synchronization request; the block information includes the block header, transaction read information, transaction write information, and target node signature of the requested transaction block indicated by the block information synchronization request; The block header, transaction read information, transaction write information, and target node signature of the requested transaction block are verified. When the block information of the requested transaction block is verified, the block data sent by the data sending node based on the block data synchronization request is obtained, and the block data is written into the blockchain.

2. The method according to claim 1, characterized in that, The number of data sending nodes is N; N is a positive integer. The step of sending a block information synchronization request to the data sending node and sending a block data synchronization request to the data sending node includes: Obtain the maximum synchronization height and the first block height, and obtain the number N of the data sending nodes; the first block height refers to the maximum block height of the first transaction block included by the data request node; The number of blocks to be synchronized for the data request node is determined based on the maximum synchronization height and the first block height. Based on the number of blocks to be synchronized and N, determine the first block request range corresponding to each of the N data sending nodes; Based on the first block request range corresponding to the N data sending nodes respectively, block information synchronization requests are sent to the N data sending nodes respectively, and block data synchronization requests are sent to the N data sending nodes respectively.

3. The method according to claim 1, characterized in that, The verification of the block header, transaction read information, transaction write information, and target node signature of the requested transaction block includes: Obtain the transaction read set root from the transaction read information, generate the request write set root based on the transaction write information, and combine the request write set root with the transaction read set root to form the request read write set root; Obtain the block read / write set root of the requested transaction block from the block header of the requested transaction block; If the root of the request read / write set is the same as the root of the block read / write set, and the signature verification of the target node is successful, then the block information verification of the request transaction block is confirmed to be successful.

4. The method according to claim 1, characterized in that, The verification of the block header, transaction read information, transaction write information, and target node signature of the requested transaction block includes: The block header, transaction read information, and transaction write information of the requested transaction block are verified to obtain the information verification result; Obtain the target consensus node corresponding to the target node signature of the requested transaction block, verify the target node signature based on the target consensus node, and obtain the signature verification result; If the information verification result is a successful information verification result, and the signature verification result is a successful signature verification result, then it is determined that the block information verification of the requested transaction block has passed. If the information verification result is an information verification failure result, or the signature verification result is a signature verification failure result, then it is determined that the block information verification of the requested transaction block has failed.

5. The method according to claim 4, characterized in that, The number of requested transaction blocks is M, where M is a positive integer; The process of verifying the signature of the target node based on the target consensus node to obtain a signature verification result includes: If the p-th request transaction block is the first or last request transaction block among M request transaction blocks, then if the target consensus node corresponding to the target node signature of the p-th request transaction block is the data sending node, the signature verification failure result is determined as the signature verification result of the p-th request transaction block; if the target consensus node corresponding to the target node signature of the p-th request transaction block is not the data sending node, the signature verification success result is determined as the signature verification result of the p-th request transaction block; p is a positive integer less than or equal to M; If the p-th request transaction block is neither the first nor the last of the M request transaction blocks, then if the target consensus node corresponding to the target node signature of the p-th request transaction block is the same as the target consensus node corresponding to the target node signature of the (p-1)-th request transaction block, the signature verification failure result is determined as the signature verification result of the p-th request transaction block; if the p-th target consensus node is different from the (p-1)-th target consensus node, the signature verification pass result is determined as the signature verification result of the p-th request transaction block.

6. The method according to claim 4, characterized in that, The number of requested transaction blocks is M, where M is a positive integer; The process of verifying the signature of the target node based on the target consensus node to obtain a signature verification result includes: Deduplication is performed on the target consensus nodes corresponding to the M request transaction blocks to obtain the deduplicated nodes; Obtain the first number of nodes after deduplication, and obtain the number of nodes that have passed consensus. If the number of the first nodes is less than the number of nodes that have passed the consensus, then the signature verification failure result is determined as the signature verification result of the M request transaction blocks; If the number of the first nodes is greater than or equal to the number of nodes that have passed consensus, then the signature verification result is determined as the signature verification result of the M request transaction blocks.

7. The method according to claim 1, characterized in that, The method further includes: When receiving block data sent by the data sending node based on the block data synchronization request, look up the block information corresponding to the block data; If the block information is not found, or if the verification of the block information fails, the block data is cached. When the block information of the requested transaction block is verified, the step of obtaining the block data sent by the data sending node based on the block data synchronization request includes: When the block information of the requested transaction block is verified, the cached block data is obtained.

8. The method according to claim 1, characterized in that, The number of requested transaction blocks is M, where M is a positive integer; the method further includes: Retrieve the transaction write information for the p-th requested transaction block; p is a positive integer less than or equal to M; If the transaction write information of the p-th request transaction block is data of the first type, then the first state data is updated according to the transaction write information of the p-th request transaction block; the first type refers to the data type of the transaction write data. If the transaction write information of the p-th request transaction block is data of the second type, then obtain the transaction write information of the (p+1)-th request transaction block; the second type refers to the hash type.

9. The method according to claim 1, characterized in that, When the block information of the requested transaction block is verified, the method further includes: If there is an unsynchronized block range within the range of blocks to be synchronized, then a second block request range is obtained from the unsynchronized block range; the range of blocks to be synchronized refers to the block height range of the transaction blocks that the data request node is missing. Based on the second block request range, continue to send block information synchronization requests to the data sending node, and store the second block request range; When the block data is written into the blockchain, a block data synchronization request is sent to the data sending node based on the second block request range.

10. The method according to claim 1, characterized in that, The method further includes: Obtain the first block request range corresponding to the block information synchronization request and the block data synchronization request, and obtain the functional block range associated with the block query function; the functional block range refers to the block height range of the transaction blocks targeted by the block query function. When the block data is written into the blockchain, the functional block range is updated based on the first block request range; the updated functional block range includes the first block request range.

11. A method for synchronizing block data, characterized in that, The method is executed by the data sending node, and the method includes: When a block information synchronization request is received from a data request node, the block header, transaction read information, transaction write information, and target node signature of the requested transaction block indicated by the block information synchronization request are obtained. The block header, transaction read information, transaction write information, and target node signature of the requested transaction block are combined to form the block information of the requested transaction block. The block information is then sent to the data request node so that the data request node can verify the block information of the requested transaction block. When a block data synchronization request is received from the data request node, the block data of the requested transaction block indicated by the block data synchronization request is sent to the data request node, so that the data request node writes the block data into the blockchain when the block information of the requested transaction block is verified.

12. The method according to claim 11, characterized in that, The process of obtaining the block information synchronization request indicates the block header, transaction read information, transaction write information, and target node signature of the requested transaction block, including: Obtain the block header and target node signature of the requested transaction block indicated by the block information synchronization request; Obtain the transaction data included in the requested transaction block, obtain transaction read data based on the transaction data, perform hash processing on the transaction read data to obtain the transaction read set root corresponding to the transaction data, and determine the transaction read set root as the transaction read information of the requested transaction block; Obtain transaction write data from the transaction data, and convert the transaction write data into transaction write information.

13. The method according to claim 12, characterized in that, The number of requested transaction blocks is M, where M is a positive integer; The step of converting the transaction write data into transaction write information includes: Obtain the transaction key data included in the transaction write data of the k-th requested transaction block, and obtain the transaction key data in the transaction write data corresponding to the first to the (k-1)-th requested transaction blocks respectively; k is a positive integer less than or equal to M; the block height of the k-th requested transaction block is less than the block height of the (k-1)-th requested transaction block; If the first transaction key data includes the (k-1)th transaction key data, then the transaction write data of the kth request transaction block is hashed to obtain the transaction write information of the kth request transaction block. If the first transaction key data to the (k-1)th transaction key data does not include the kth transaction key data, then the transaction write data of the kth requested transaction block is determined as the transaction write information of the kth requested transaction block.

14. A blockchain data synchronization device, characterized in that, The device is suitable for data request nodes, and the device includes: The request sending module is used to send a block information synchronization request to the data sending node and to send a block data synchronization request to the data sending node. The information acquisition module is used to acquire the block information sent by the data sending node based on the block information synchronization request; the block information includes the block header, transaction read information, transaction write information and target node signature of the requested transaction block indicated by the block information synchronization request; The information verification module is used to verify the block header, transaction read information, transaction write information, and target node signature of the requested transaction block; The data synchronization module is used to obtain the block data sent by the data sending node based on the block data synchronization request when the block information of the requested transaction block is verified, and write the block data into the blockchain.

15. A blockchain data synchronization device, characterized in that, The device is suitable for a data transmission node, and the device includes: The data acquisition module is used to acquire the block header, transaction read information, transaction write information, and target node signature of the requested transaction block indicated by the block information synchronization request when it receives a block information synchronization request sent by a data request node. The information processing module is used to assemble the block header, transaction read information, transaction write information and target node signature of the requested transaction block into block information of the requested transaction block, and send the block information to the data request node so that the data request node can verify the block information of the requested transaction block; The data sending module is used to send the block data of the requested transaction block indicated by the block data synchronization request to the data request node when it receives the block data synchronization request sent by the data request node, so that the data request node writes the block data into the blockchain when the block information of the requested transaction block is verified.

16. A computer device, characterized in that, Includes processor, memory, and input / output interfaces; The processor is connected to the memory and the input / output interface respectively, wherein the input / output interface is used to receive data and output data, the memory is used to store computer programs, and the processor is used to call the computer programs so that the computer device executes the method according to any one of claims 1-10, or executes the method according to any one of claims 11-13.

17. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded and executed by a processor to cause a computer device having the processor to perform the method of any one of claims 1-10, or to perform the method of any one of claims 11-13.

18. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the method according to any one of claims 1-10, or perform the method according to any one of claims 11-13.

Images