CN111241593A

CN111241593A - Data synchronization method and device for block chain nodes

Info

Publication number: CN111241593A
Application number: CN202010000796.6A
Authority: CN
Inventors: 陈锐
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2020-01-02
Filing date: 2020-01-02
Publication date: 2020-06-05
Also published as: WO2021135744A1

Abstract

An embodiment of the present specification provides a data synchronization method for a blockchain node, including: dividing each data to be synchronized of a first block chain node into a plurality of data sets to be synchronized; assigning the plurality of sets of data to be synchronized to a plurality of second blockchain nodes; sending a data synchronization request message to a second block link point corresponding to each data set to be synchronized so as to request to acquire data to be synchronized in the data set to be synchronized; and acquiring the data to be synchronized in the corresponding data sets to be synchronized from the second block chain node corresponding to each data set to be synchronized.

Description

Data synchronization method and device for block chain nodes

Technical Field

The embodiments of the present disclosure relate to the field of blockchain technologies, and in particular, to a data synchronization method and apparatus for blockchain nodes.

Background

The blockchain system is a decentralized, distributed data storage system that is participated in by multiple nodes. Once data is written to the blockchain on each node, on one hand, it means that the data is disclosed in the blockchain network, and on the other hand, the data written to the blockchain is also difficult to delete and tamper with. In addition, the centralized facility may also store data in a manner similar to blockchain storage (which may be considered centralized blockchain storage).

There are typically multiple participating nodes (blockchain nodes) in a blockchain system. The consistency of respective data is ensured among the existing participating nodes through a consensus protocol. However, when a participating node fails, a new participating node joins, or other various reasons occur, data of a participating node may be caused to lag other normal participating nodes. Therefore, the blockchain system needs to use a data synchronization protocol to ensure that the laggard participating nodes can make the locally maintained data catch up with other normal participating nodes, thereby participating in the normal consensus process. When a participating node finds that the data maintained by itself lags behind other normal nodes, it can initiate a data synchronization process, i.e. request the normal participating nodes for the missing data. The regular node may send the data requested by the laggard participating node to the laggard participating node in a reply message when receiving the data request.

Disclosure of Invention

In view of the foregoing, embodiments of the present specification provide a data synchronization method and apparatus for a blockchain node.

According to an aspect of embodiments of the present specification, there is provided a data synchronization method for a blockchain node, including: dividing each data to be synchronized of a first block chain node into a plurality of data sets to be synchronized; assigning the plurality of sets of data to be synchronized to a plurality of second blockchain nodes; sending a data synchronization request message to a second block link point corresponding to each data set to be synchronized so as to request to acquire data to be synchronized in the data set to be synchronized; and acquiring the data to be synchronized in the corresponding data sets to be synchronized from the second block chain node corresponding to each data set to be synchronized.

Optionally, in an example, the dividing the data to be synchronized of the first blockchain node into a plurality of data sets to be synchronized may include: and dividing each data to be synchronized into a plurality of data sets to be synchronized based on the block chain link point list information in the block chain system.

Optionally, in an example, the dividing the data to be synchronized into a plurality of data sets to be synchronized may include: acquiring load information of the plurality of second block chain nodes; and partitioning each data to be synchronized into a plurality of data sets to be synchronized based on load information of the plurality of second blockchain nodes.

Optionally, in an example, after sending the data synchronization request message to the second block link point corresponding to each set of data to be synchronized, the method may further include: and adjusting each data set to be synchronized based on the response result of the second block chain node corresponding to the each data set to be synchronized to the corresponding data synchronization request message.

Optionally, in an example, the response result may include: the response speed of the second block link point to the corresponding data synchronization request message; and/or the amount of data to be synchronized received from the second blockchain node.

Optionally, in an example, the respective data to be synchronized may include data of a block to be synchronized.

According to another aspect of the present disclosure, there is also provided a data synchronization apparatus for a blockchain node, including: the data to be synchronized dividing unit is used for dividing each data to be synchronized of the first block chain node into a plurality of data sets to be synchronized; the data to be synchronized distribution unit is used for distributing the data sets to be synchronized to a plurality of second block chain nodes; the data synchronization request sending unit is used for sending a data synchronization request message to the second block chain nodes corresponding to each data set to be synchronized so as to request to acquire the data to be synchronized in the data set to be synchronized; and the data to be synchronized acquisition unit acquires the data to be synchronized in the corresponding data sets to be synchronized from the chain link points of the second blocks corresponding to the data sets to be synchronized.

Optionally, in an example, the data to be synchronized dividing unit divides each data to be synchronized into a plurality of data sets to be synchronized based on the information of the list of block link points in the block chain system.

Optionally, in an example, the data to be synchronized splitting unit may include: the load information acquisition module is used for acquiring the load information of the plurality of second block chain nodes; and a data to be synchronized dividing module which divides each data to be synchronized into a plurality of data to be synchronized sets based on the load information of the plurality of second blockchain nodes.

Optionally, in an example, the apparatus may further include: and the data sets to be synchronized adjusting unit is used for adjusting each data set to be synchronized based on the response result of the second block chain node corresponding to each data set to be synchronized to the corresponding data synchronization request message after the data synchronization request message is sent to the second block chain node corresponding to each data set to be synchronized.

According to another aspect of embodiments of the present specification, there is also provided a computing device including: at least one processor; and a memory storing instructions that, when executed by the at least one processor, cause the at least one processor to perform the method as described above.

According to another aspect of embodiments herein, there is also provided a non-transitory machine-readable storage medium storing executable instructions that, when executed, cause the machine to perform the method as described above.

By means of the method and the device in the embodiment of the present specification, the data to be synchronized is divided into the plurality of data sets to be synchronized, and the plurality of data sets to be synchronized are distributed to the plurality of second block chain nodes, so that resources occupied by the data synchronization process can be distributed to the plurality of second block chain nodes, and the load of a single second block chain node is prevented from being too high.

Drawings

A further understanding of the nature and advantages of the contents of the embodiments of the present specification may be realized by reference to the following drawings. In the drawings, similar components or features may have the same reference numerals. The accompanying drawings, which are included to provide a further understanding of the embodiments of the invention and are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and together with the detailed description serve to explain the embodiments of the invention. In the drawings:

FIG. 1 illustrates a schematic diagram of an example of an environment that may be used to perform a data synchronization method in accordance with an embodiment of the present specification;

FIG. 2 shows a schematic diagram of an example of a system architecture for performing a data synchronization method in accordance with an embodiment of the present specification;

FIG. 3 is a flow chart for illustrating an exemplary application scenario of a data synchronization method according to an embodiment of the present specification;

FIG. 4 is a flow diagram of a method of data synchronization according to one embodiment of the present description;

FIG. 5 is a flow diagram of one example of a process for segmenting data to be synchronized in a method of data synchronization according to one embodiment of the present description;

FIG. 6 is a flow diagram of one example of a data set adjustment process to be synchronized in a number synchronization method according to one embodiment of the present description;

FIG. 7 is a block diagram of a data synchronization apparatus according to one embodiment of the present description;

fig. 8 is a block diagram showing a configuration of an example of a data division unit to be synchronized in the data synchronization apparatus shown in fig. 7; and

fig. 9 is a block diagram of a computing device for a data synchronization method according to one embodiment of the present specification.

Detailed Description

The subject matter described herein will be discussed with reference to example embodiments. It should be understood that these embodiments are discussed only to enable those skilled in the art to better understand and thereby implement the subject matter described herein, and are not intended to limit the scope, applicability, or examples set forth in the claims. Changes may be made in the function and arrangement of elements discussed without departing from the scope of the embodiments of the disclosure. Various examples may omit, substitute, or add various procedures or components as needed. In addition, features described with respect to some examples may also be combined in other examples.

As used herein, the term "include" and its variants mean open-ended terms in the sense of "including, but not limited to. The term "based on" means "based at least in part on". The terms "one embodiment" and "an embodiment" mean "at least one embodiment". The term "another embodiment" means "at least one other embodiment". The terms "first," "second," and the like may refer to different or the same object. Other definitions, whether explicit or implicit, may be included below. The definition of a term is consistent throughout the specification unless the context clearly dictates otherwise.

The data synchronization method and apparatus of the embodiments of the present specification will now be described with reference to the accompanying drawings.

The block chain is a chain data structure formed by connecting and combining data blocks according to a time sequence, and the data blocks are guaranteed to be not falsifiable and not forged in a cryptographic mode. A block chain includes one or more blocks. Each chunk in the chain of chunks is linked to the immediately preceding chunk in the chain of chunks by including a cryptographic hash of the preceding chunk. Each chunk also includes a timestamp, a cryptographic hash of the chunk, and one or more transactions (transactions). Transactions that have been verified by nodes of the blockchain network are hashed and form a Merkle tree. In a Merkle tree, data at leaf nodes is hashed and, for each branch of the Merkle tree, all hash values of the branch are concatenated at the root of the branch. The above process is performed for the Merkle tree up to the root node of the entire Merkle tree. The root node of the Merkle tree stores a hash value representing all the data in the Merkle tree. When a hash value claims to be a transaction stored in the Merkle tree, a quick verification can be performed by determining whether the hash value is consistent with the structure of the Merkle tree.

A blockchain is a data structure used to store transactions. A blockchain network is a network of computing nodes used to manage, update and maintain one or more blockchain structures. As described above, the blockchain network may include a public blockchain network, a private blockchain network, or a federated blockchain network.

In a public blockchain network, the consensus process is controlled by nodes of the consensus network. For example, there may be thousands of entity co-processes in a public blockchain network, each entity operating at least one node in the public blockchain network. Thus, a public blockchain network may be considered a public network of participating entities. In some examples, most entities (nodes) must sign each chunk in sequence and add the signed chunk to the blockchain of the blockchain network. An example of a public blockchain network may include a particular peer-to-peer payment network. Furthermore, the term "blockchain" does not particularly refer to any particular blockchain.

Public blockchain networks support public transactions. Public transactions are shared among all nodes within a public blockchain network and are stored in a global blockchain. A global blockchain refers to a blockchain that is replicated across all nodes. To achieve consensus (e.g., agree to add blocks to a blockchain), a consensus protocol is implemented within a public blockchain network. Examples of consensus protocols include, but are not limited to: proof of work (POW), proof of rights (POS), and proof of authority (POA). In the embodiments of the present specification, POW is taken as a non-limiting example.

A private blockchain network is provided for a particular entity. The read-write authority of each node in the private blockchain network is strictly controlled. Thus, private blockchain networks, also commonly referred to as licensed networks, limit who is allowed to participate in the network and the level of network participation (e.g., only in certain transaction scenarios). In private blockchain networks, various types of access control mechanisms may be used (e.g., existing participants voting for adding new entities, regulatory body controlled permissions, etc.).

A federation blockchain network is private between participating entities. In a federated blockchain network, the consensus process is controlled by an authorizing node. For example, a federation consisting of several (e.g., 10) entities (e.g., financial institutions, insurance companies) may operate a federated blockchain network, each entity operating at least one node in the federated blockchain network. Thus, a federated blockchain network can be considered a private network of participating entities. In some examples, each participating entity (node) must sign each chunk in sequence and add the chunk to the chain of chunks. In some examples, each tile may be signed by a subset of participating entities (nodes) (e.g., at least 7 entities) and added to the tile chain.

Embodiments of the present specification embodiments are described in detail with reference to a federated blockchain network in the present specification embodiments. However, it is contemplated that embodiments of the present specification can be implemented in any suitable blockchain network.

Blockchains are tamper-resistant shared digital ledgers that record transactions in public or private peer-to-peer networks. The ledger is distributed to all member nodes in the network and asset transaction histories occurring in the network are permanently recorded in blocks.

The consensus mechanism ensures that all network nodes in the distributed blockchain network perform transactions in the same order and then write the same ledger. The consensus model aims at solving the byzantine problem. In the byzantine problem, components such as servers or network nodes in a distributed blockchain network may fail or intentionally propagate erroneous information to other nodes. Other network nodes have difficulty declaring the component as a failure and excluding it from the blockchain network because they need to agree first on which network node failed first.

FIG. 1 illustrates a schematic diagram of an example of an environment 100 that may be used to perform a data synchronization method in accordance with embodiments of the present specification. In some examples, environment 100 enables entities to participate in blockchain network 102. As shown in FIG. 1, environment 100 includes a network 104, and computing devices/

systems

106, 108. In some examples, the network 104 may include a Local Area Network (LAN), a Wide Area Network (WAN), the internet, or a combination thereof, and connects websites, user devices (e.g., computing devices), and backend systems. In some examples, network 104 may be accessed through wired and/or wireless communication links. In some examples, computing devices/

systems

106, 108 communicate with each other over network 104, as well as with blockchain network 102 over network 104, and nodes (or node devices) in blockchain network 102 communicate over network 104. In general, the network 104 represents one or more communication networks. In some cases, the computing devices/

systems

106, 108 may be nodes of a cloud computing system (not shown), or each computing device/

system

106, 108 may be a separate cloud computing system that includes multiple computers interconnected by the network 104 and functions as a distributed processing system.

In the illustrated example, each of the computing devices/

systems

106, 108 may comprise any suitable computing system capable of participating as a node in the blockchain network 102. Examples of computing devices/systems include, but are not limited to, servers, desktop computers, laptops, tablet devices, smartphones, and the like. In some examples, one or more computer-implemented services may be installed on the computing devices/

systems

106, 108 for interacting with the blockchain network 102. For example, the computing device/system 106 may have installed thereon a service of a first entity (e.g., user a), such as a transaction management system used by the first entity to manage its transactions with one or more other entities (e.g., other users). The computing device/system 108 may have installed thereon a service of a second entity (e.g., user B), such as a transaction management system used by the second entity to manage its transactions with one or more other entities (e.g., other users). In the example of fig. 1, the blockchain network 102 is represented as a peer-to-peer network of nodes, and the computing devices/

systems

106, 108 act as nodes for first and second entities participating in the blockchain network 102, respectively.

Fig. 2 shows a schematic diagram of an example of a system architecture 200 for performing a data synchronization method according to an embodiment of the present description. An example of system architecture 200 includes

participant systems

202, 204, 206 corresponding to participant a, participant B, and participant C, respectively. Each participant (e.g., user, enterprise) participates in blockchain network 212, which is provided as a peer-to-peer network. The blockchain network 212 includes a plurality of nodes 214, wherein at least some of the nodes 214 record information in blockchain 216, and the recorded information is not alterable. Although a single blockchain 216 is schematically shown within blockchain network 212, multiple copies of blockchain 216 may be provided and maintained in blockchain network 212, as described in detail later.

In the illustrated example, each

participant system

202, 204, 206 is provided by or as participant a, participant B, and participant C, respectively, and acts as a corresponding node 214 within the blockchain network 212. As used herein, a node generally refers to a single system (e.g., computer, server) that is connected to the blockchain network 212 and enables the respective participants to participate in the blockchain network. In the example shown in fig. 2, a participant corresponds to each node 214. However, one participant may operate multiple nodes 214 within blockchain network 212, and/or multiple participants may share a single node 214. In some examples, the

participant systems

202, 204, 206 communicate with the blockchain network 212 using a protocol (e.g., hypertext transfer protocol secure (HTTPS)) and/or using Remote Procedure Calls (RPCs), or communicate over the blockchain network 212.

The node 214 may have different participation in the blockchain network 212. For example, some nodes 214 may participate in the consensus process (e.g., as miners' nodes that add tiles to the blockchain 216), while other nodes 214 do not participate in the consensus process. As another example, some nodes 214 store a full copy of blockchain 216, while other nodes 214 store only partial copies of blockchain 216. In the example of fig. 2, the

participant systems

202, 204, 206 each store a complete copy 216', 216 "' of the chain of blocks 216.

A block chain (e.g., block chain 216 in fig. 2) consists of a series of blocks, each of which stores data. Examples of data may include transaction data representing transactions between two or more parties. In the present specification embodiments, transactions are used as non-limiting examples, and it is contemplated that any suitable data may be stored in the blockchain (e.g., documents, images, video, audio). Examples of transactions may include, but are not limited to, exchanging things of value (e.g., assets, products, services, and currency, etc.). Transaction data is unalterably stored in the blockchain.

The transaction data is hashed prior to storage in the block. The hash process is a process of converting transaction data (provided as character string data) into a hash value of a fixed length (also provided as character string data). After the transaction data is subjected to the hash processing, even if slight change occurs in the transaction data, completely different hash values can be obtained. The hash value is typically generated by hashing the transaction data using a hash function. Examples of hash functions include, but are not limited to, Secure Hash Algorithm (SHA) -256, which outputs a 256-bit hash value.

Transaction data for a plurality of transactions may be stored in the block after being hashed. For example, two transaction data are hashed to obtain two hash values, and then the two obtained hash values are hashed again to obtain another hash value. This process is repeated until a single hash value is obtained for all transactions to be stored in the block. This hash value is called a Merkle root hash and is stored at the head of the chunk. Any change to a transaction will cause its hash value to change, eventually causing the Merkle root hash value to change.

The blocks are added to the block chain by a consensus protocol. Multiple nodes in a blockchain network participate in a consensus protocol and add blocks to the blockchain after contention. Such nodes are referred to as miner nodes (or accounting nodes). The POW introduced above is used as a non-limiting example.

The miner node performs a consensus process to add the transaction (the corresponding tile) to the chain of tiles. Although multiple miner nodes participate in the consensus process, only one miner node may write a block into the blockchain. That is, the miners nodes compete in the consensus process to add their blocks to the blockchain. In more detail, the miner node periodically collects pending transactions from the transaction pool (e.g., until a predetermined limit, if any, on the number of transactions that may be included in the block is reached). The transaction pool includes transaction messages from participants in the blockchain network. The miner node creates a block and adds the transaction to the block. Before adding a transaction to a block, the miner node checks whether there is a transaction in the block of the blockchain in the transaction to be added. If the transaction has been added to another block, the transaction will be discarded.

The mineworker node generates a chunk header, hashes all transactions in the chunk, and combines the hash values in pairs to generate further hash values until a single hash value (Merkle root hash) is obtained for all transactions in the chunk. The Merkle root hash is then added to the chunk header. The miners also determine the hash value of the latest chunk in the blockchain (i.e., the last chunk added to the blockchain). The mineworker node may also add a random value (a noune value) and a timestamp in the block header. During the mining process, the miners' nodes attempt to find hash values that satisfy the required parameters. The mineworker node continually changes the nonce value until a hash value is found that meets the required parameters.

Each miner in the blockchain network attempts to find a hash value that satisfies the required parameters and competes with each other in this manner. Finally, one miner node finds a hash value that satisfies the required parameters and advertises the hash value to all other miner nodes in the blockchain network. Other miners nodes verify the hash value, and if determined to be correct, verify each transaction in the block, accept the block, and append the block to their blockchain copy. In this way, the global state of the blockchain is made consistent across all miner nodes within the blockchain network. The above process is a POW consensus protocol.

In the example provided in fig. 2, party a wants to send a certain amount of funds to party B. Party a generates a transaction message and sends the transaction message to the blockchain network, which is added to the transaction pool. Each mineworker node in the blockchain network creates a block and obtains transactions from the transaction pool and adds the transactions to the block. In this manner, the transaction issued by party a is added to the block of the miner node.

In some blockchain networks, cryptographic techniques are implemented to maintain privacy of transactions. For example, if two nodes want to maintain transaction privacy so that other nodes in the blockchain network cannot learn the transaction details, the nodes may encrypt the transaction data. Examples of encryption methods include, but are not limited to, symmetric encryption and asymmetric encryption. Symmetric encryption refers to an encryption process that uses a single key for both encryption (to generate ciphertext from plaintext) and decryption (to generate plaintext from ciphertext). In symmetric encryption, multiple nodes may use the same key, so each node may encrypt/decrypt transaction data.

Asymmetric encryption refers to encryption using a key pair. Each key pair comprises a private key and a public key, the private key being known only to the respective node, and the public key being known to any or all other nodes in the blockchain network. A node may encrypt data using a public key of another node and may decrypt the encrypted data using a private key of the other node. For example, refer again to fig. 1. Party a may encrypt data using party B's public key and send the encrypted data to party B. Messages encrypted using a node's public key can only be decrypted using the node's private key.

Asymmetric encryption is used to provide a digital signature that enables a party in a transaction to confirm the validity of other parties in the transaction and the transaction. For example, a node may digitally sign a message, and another node may confirm that the message was sent by the node based on the digital signature of party a. Digital signatures can also be used to ensure that messages are not tampered with during transmission. For example, refer again to fig. 1. Party a will send a message to party B. Party a generates a hash value of the message and then encrypts the hash value using its private key to generate a digital signature. Party a attaches the digital signature to the message and sends the message with the digital signature to party B. Party B decrypts the digital signature using party a's public key, thereby decrypting the corresponding hash value. Party B hashes the received message to get another hash value and then compares the two hash values. If the hash values are the same, party B can confirm that the message is indeed from party A and has not been tampered with.

Fig. 3 is a flowchart for explaining an exemplary application scenario of the data synchronization method according to an embodiment of the present specification.

As shown in fig. 3, a first block link point may send a highest block request message to a second block link point to request a determination of the highest block information stored at the second block link point, at 302. The first blockchain node may be any participating node in the blockchain system, and the second blockchain node may be any participating node other than the first blockchain node.

The second block-link point may then send the locally stored highest block information to the first block-link point in response to the highest block request message, at block 304.

In one example, each tile link point in the tile chain system may periodically broadcast a highest tile request message to a second tile link point. When other blockchain nodes listen to the highest block request message, the locally stored block height of the highest block can be sent to the sender of the highest block request message. The block height is used to indicate the order of the blocks in the block chain. For example, each block may be numbered sequentially from the starting block (i.e., the first block in the block chain), which may be the block height of the corresponding block.

In another example, each blockchain node may periodically send a highest block request message to one or more second blockchain nodes that it trusts. The second block link point trusted by the first block link node may be determined based on the interaction history data of the first block link point and each second block link node, for example, the block link point with the shortest message response delay or the block link node with the highest verification passing rate of data received from the other side may be selected as the trusted node. In addition, the trusted node information can be maintained locally, so that the trusted second blockchain node can be acquired from the trusted node information.

Upon receiving the highest block information sent by the second blockchain node, the first blockchain node determines whether the local block data lags the second blockchain node based on the received highest block information and the highest block information at the first blockchain link point, at 306. In this specification, data lag means that, for a certain type of data (e.g., block data in this example), the type of data stored at a certain block link point is missing with respect to other block link points. For example, if the highest block information of the second block chain node indicates that the block height of the highest block at the second block link point is 100 and the block height of the highest block at the first block link point is 80, it indicates that the block data at the first block link point lags behind the second block chain node. In this specification, a block link point where some type of locally owned data is missing from other block link nodes may be referred to as a laggard node. The laggard nodes can be the blockchain nodes which are added into the blockchain network and have data loss due to faults or network delay and the like, and can also be the nodes newly added into the blockchain network.

When it is determined that the block data lags behind the second blockchain node, the first blockchain node sends a data synchronization request message to the second blockchain node to request acquisition of locally missing block data at 308. In this specification, a process of complementing local block data to be consistent with other blockchain nodes may be referred to as a block synchronization data process. For example, in the above example, the block data at the first block link point is complemented from a block with a block height of 80 to a block with a block height of 100 to coincide with the process of the second block link point, i.e., the block data synchronization process. In the data synchronization request message, data information of the block to be synchronized may be included, and for example, a block height range (e.g., 81 to 100) of the data of the block to be synchronized may be included.

The second blockchain node, after receiving the blockdata request message, assembles a plurality of blockdata requested by the data synchronization request message into a response message in response to the data synchronization request at block 310. Since the size of a single message is usually limited in the blockchain network (for example, the size of a single message is limited to be not more than 16M), the second blockchain node may assemble the response message in batches, that is, when all the block data to be synchronized cannot be transmitted to the first blockchain node by using one response message, the block data to be synchronized requested by the first blockchain node may be assembled into a plurality of batch response messages.

After the acknowledgement message assembly is complete, the second blockchain node sends the assembled acknowledgement message to the first blockchain node at block 312. When the response messages are assembled in batches, the respective batch response messages may be sent to the first blockchain node.

After the first block link node receives the reply message, the block data in the reply message is verified at 314, and a determination is made as to whether the block data verifies at 316. The block data verification may include a verification process such as block data integrity verification to verify whether the received block data is correct. The block data verification process may be performed by any verification method known in the art, for example, by verifying the signature data in the block data. When the block data is verified, the first block link node adds the verified block data to the local block chain at 318 to implement the block data synchronization process.

Although an application scenario of the data synchronization method according to the embodiment of the present specification is described in fig. 3 by taking a block data synchronization process as an example, the data synchronization method according to the present specification may be applied to a synchronization process for arbitrary data. For example, in the block data consensus process, when each block link point lacks a consensus message in a partial consensus phase, and thus requests other block link points to synchronize the missing consensus message, the data synchronization method of the present specification may also be applied.

Examples of the data synchronization method of the embodiment of the present specification are explained below with reference to fig. 4 to 6.

FIG. 4 is a flow diagram of a method of data synchronization according to one embodiment of the present description.

As shown in FIG. 4, at block 402, each data to be synchronized of a first blockchain node is partitioned into a plurality of data sets to be synchronized. Then, at block 404, a plurality of sets of data to be synchronized are assigned to a plurality of second blockchain nodes.

Each data to be synchronized may be partitioned in any manner. In one example, each data to be synchronized may be partitioned into multiple data sets to be synchronized based on the blockchain link point list information in the blockchain system. For example, each data to be synchronized may be equally divided into a corresponding number of data sets to be synchronized based on the number of block chain nodes in the block chain link point list information. In another example, the information of whether each block chain node is a trust node may be further included in the block chain node list information, so that the partition may be performed based on the number of trust nodes. In another example, the block chain link point list information may further include a trust level of each block chain node, so that the data to be synchronized may be partitioned based on the trust level. For example, more data to be synchronized may be allocated to a blockchain node with a higher trust level, and less data to be synchronized may be allocated to a blockchain node with a trust level lower than a predetermined level or no data to be synchronized may be allocated thereto. In another example, the data to be synchronized may also be partitioned with reference to FIG. 5, described below.

After assigning each set of data to be synchronized to each second block link point, at block 406, a data synchronization request message is sent to the second block link point corresponding to each set of data to be synchronized to request to acquire the data to be synchronized in the set of data to be synchronized. The data synchronization request message may include corresponding information of the data sets to be synchronized. For example, when the data to be synchronized is tile data, the tile height of each data to be synchronized in the set of data to be synchronized may be included. When the data to be synchronized is a consensus phase message, each consensus phase message identification to be synchronized may be included. After receiving the data synchronization request message, the second blockchain node may obtain the data to be synchronized requested by the first blockchain node.

Then, at block 408, the first blockchain node obtains the data to be synchronized in the corresponding data set to be synchronized from the second blockchain node corresponding to each data set to be synchronized.

In one example, when the data to be synchronized has a data order (e.g., the block data has an order in the block chain), for each data to be synchronized, a data synchronization request message for the data to be synchronized may be transmitted to the corresponding block chain node after receiving the previous data to be synchronized. For example, each data to be synchronized may be divided into a plurality of data sets to be synchronized based on the order of the data to be synchronized, and then a corresponding data request to be synchronized may be sent to the corresponding second block link point based on the data order of the data sets to be synchronized. For example, when the block height of the block data to be synchronized is 80 to 120, the block data to be synchronized can be sequentially divided into four sets of block data to be synchronized, such as 80-90, 91-100, 101, 110, 111 and 120, from the block height 80 to 120. Then, firstly, a data synchronization request message for 80-90 is sent to one of the blockchain nodes, and after receiving the corresponding block data to be synchronized, a data request to be synchronized for 91-100 is sent to another second blockchain node. Furthermore, the data order in the data sets to be synchronized may not be continuous, and in this example, the data synchronization request message may be sent separately for each data set to be synchronized. Taking the block data as an example, when the previous block data to be synchronized cannot be received or cannot pass the local verification of the first block chain node, even if the subsequent block data to be synchronized is received, the situation that the block data to be synchronized cannot be linked temporarily occurs, and at this time, the storage space is consumed to store the subsequent block data to be synchronized. Thus, with this example, storage resource utilization can be avoided and local storage resources can be allocated rationally.

In the process of performing data synchronization, if multiple data to be synchronized exist, if the data to be synchronized is requested to the same second block link point, problems such as too high load of the second block link point or no response of the second block link node for a long time may be caused. By the embodiment, the synchronization load of the data to be synchronized can be dispersed to the plurality of second block chain nodes, so that the resource of one node is prevented from being excessively occupied. In one example, when the trust level information is included in the block chain node list information, the block chain nodes may be sorted based on the trust level of each block chain node. When the data to be synchronized is divided, the number of the data sets to be synchronized may be determined based on the number of the data to be synchronized, and the second block chain nodes with higher trust levels and corresponding numbers may be selected from the sorting results of the block chain link points.

It should be noted that, although the data to be synchronized splitting process and the data to be synchronized allocating process are illustrated as two processes in fig. 4, in other examples of the present specification, there may be an intersection and a fusion of the two. For example, a predetermined number of data to be synchronized may be allocated to each second block link node in each allocation procedure in the order of the data of the blocks to be synchronized, and a next allocation procedure may be performed after one allocation procedure is completed until all the data to be synchronized are allocated to the corresponding second block link nodes. After the allocation process of all the data to be synchronized is completed, the set of data to be synchronized for each second blockchain node may be obtained.

Fig. 5 is a flowchart of one example of a data division process to be synchronized in a data synchronization method according to one embodiment of the present specification.

As shown in fig. 5, at block 502, load information for a plurality of second blockchain nodes is obtained. The load information of each second blockchain node may be determined based on the history of interactions of the second blockchain node with the first blockchain node. For example, the load information of the second blockchain node may be determined based on information of the number of data received from the second blockchain node, the frequency of receiving data from the second blockchain node, and the like at the latest predetermined time period.

After obtaining the load information, at block 504, each data to be synchronized is partitioned into a plurality of data sets to be synchronized based on the load information of the plurality of second blockchain nodes. The second block link point with higher load may be allocated with less data to be synchronized, that is, the number of data to be synchronized in the data set to be synchronized for the second block link node may not exceed a predetermined number, or the ratio of the number of data to be synchronized to the total number of data to be synchronized may not exceed a predetermined ratio. Accordingly, the number of data to be synchronized in the data set to be synchronized for the second blockchain node with lower load may be made smaller, that is, the number of data to be synchronized in the data set to be synchronized may not be lower than a predetermined number, or the ratio of the number of data to be synchronized to the total number of data to be synchronized may not be lower than a predetermined ratio.

By the example, the data synchronization load allocated to each second block link node can be adapted to the load of the second block link node, so that the resource utilization efficiency of each second block link node is improved, the response speed of each second block link node to the data synchronization request message is improved to the greatest extent, and the data synchronization efficiency is improved.

FIG. 6 is a flow diagram of one example of a data set adjustment process to be synchronized in a number synchronization method according to one embodiment of the present description.

As shown in fig. 6, at block 602, a response result of each second chunk link point to the corresponding data synchronization request message is obtained. The response result may be a response speed of the second block link point for the corresponding data to be synchronized, or may be the amount of data to be synchronized received from the second block link point, or the amount of data to be synchronized received within a predetermined time period after the data synchronization message is sent.

Then, at block 604, each set of data to be synchronized is adjusted based on the response result of the second chunk link point corresponding to each set of data to be synchronized to the corresponding data synchronization request message. For example, a predetermined amount of data to be synchronized may be removed from the set of data to be synchronized of the second blockchain node whose response time exceeds the first predetermined time. The removed data to be synchronized may then be added to the data set to be synchronized of the second blockchain node having a response time less than a second predetermined time. The number of data to be synchronized in the set of data to be synchronized for the second blockchain node may also be reduced when the number of data to be synchronized received from the second blockchain node is below a predetermined number.

By the method and the device, the data synchronization load distributed to each second block chain node can be adjusted according to the response result of the second block chain node in the data synchronization process, so that the quantity of the data to be synchronized distributed to each second block chain node can be adapted to the real-time load of each second block chain node, and the data synchronization efficiency can be improved.

Fig. 7 is a block diagram of a data synchronization apparatus according to an embodiment of the present specification. As shown in fig. 7, the data synchronization apparatus 700 includes a data to be synchronized splitting unit 710, a data to be synchronized distributing unit 720, a data synchronization request transmitting unit 730, and a data to be synchronized acquiring unit 740.

The data to be synchronized dividing unit 710 divides each data to be synchronized of the first blockchain node into a plurality of data sets to be synchronized. The data to be synchronized dividing unit 710 may divide each data to be synchronized into a plurality of data sets to be synchronized based on the blockchain link point list information in the blockchain system. The data-to-be-synchronized allocating unit 720 allocates a plurality of data sets to be synchronized to a plurality of second blockchain nodes. The data synchronization request sending unit 730 sends a data synchronization request message to the second block link points corresponding to each data set to be synchronized to request to acquire the data to be synchronized in the data set to be synchronized. The data to be synchronized acquisition unit 740 acquires the data to be synchronized in the corresponding data sets to be synchronized from the second block link points corresponding to the respective data sets to be synchronized.

In addition, although not shown in fig. 7, the data synchronization apparatus 700 may further include a data set adjustment unit to be synchronized. The data set to be synchronized adjusting unit adjusts each data set to be synchronized based on a response result of the second block chain node corresponding to each data set to be synchronized with respect to the corresponding data synchronization request message after transmitting the data synchronization request message to the second block chain node corresponding to each data set to be synchronized.

Fig. 8 is a block diagram showing the structure of one example of a data division unit to be synchronized in the data synchronization apparatus shown in fig. 7. The data to be synchronized splitting unit 710 includes a load information acquisition module 711 and a data to be synchronized splitting module 712.

The load information acquisition module 711 acquires load information of a plurality of second block chain nodes. The data to be synchronized splitting module 712 splits each data to be synchronized into a plurality of data sets to be synchronized based on load information of the plurality of second blockchain nodes.

Embodiments of a data synchronization method and apparatus according to embodiments of the present specification are described above with reference to fig. 1 to 8. The details mentioned in the above description of the method embodiments apply equally to the embodiments of the device of the embodiments of the present description.

The data synchronization apparatus in the embodiments of the present specification may be implemented by hardware, or may be implemented by software, or a combination of hardware and software. The various embodiments in this specification are described in a progressive manner, with like reference to each other.

The data synchronization apparatus in the embodiments of the present specification may be implemented by hardware, or may be implemented by software, or a combination of hardware and software. The software implementation is taken as an example, and is formed by reading corresponding computer program instructions in the storage into the memory for operation through the processor of the device where the software implementation is located as a logical means. In embodiments of the present specification, the means for generating the blockchain may be implemented, for example, using a computing device.

Fig. 9 is a block diagram of a computing device for a data synchronization method according to one embodiment of the present specification. As shown in fig. 9, the computing device 900 includes a processor 910, a storage 920, a memory 930, a communication interface 940, and an internal bus 950, and the processor 910, the storage (e.g., non-volatile storage) 920, the memory 930, and the communication interface 940 are connected together via the bus 950. According to one embodiment, computing device 900 may include at least one processor 910, the at least one processor 910 executing at least one computer-readable instruction (i.e., an element described above as being implemented in software) stored or encoded in a computer-readable storage medium (i.e., memory 920).

In one embodiment, computer-executable instructions are stored in the memory 920 that, when executed, cause the at least one processor 910 to: dividing each data to be synchronized of a first block chain node into a plurality of data sets to be synchronized; assigning the plurality of sets of data to be synchronized to a plurality of second blockchain nodes; sending a data synchronization request message to a second block link point corresponding to each data set to be synchronized so as to request to acquire data to be synchronized in the data set to be synchronized; and acquiring the data to be synchronized in the corresponding data sets to be synchronized from the second block chain node corresponding to each data set to be synchronized.

It should be appreciated that the computer-executable instructions stored in the memory 920, when executed, cause the at least one processor 910 to perform the various operations and functions described above in connection with fig. 1-8 in the various embodiments of the present specification.

According to one embodiment, a program product, such as a non-transitory machine-readable medium, is provided. A non-transitory machine-readable medium may have instructions (i.e., elements described above as being implemented in software) that, when executed by a machine, cause the machine to perform various operations and functions described above in connection with fig. 1-8 in various ones of the embodiments of the present specification.

Specifically, a system or apparatus may be provided which is provided with a readable storage medium on which software program code implementing the functions of any of the above embodiments is stored, and causes a computer or processor of the system or apparatus to read out and execute instructions stored in the readable storage medium.

In this case, the program code itself read from the readable medium can realize the functions of any of the above-described embodiments, and thus the machine-readable code and the readable storage medium storing the machine-readable code form part of the present invention.

Examples of the readable storage medium include floppy disks, hard disks, magneto-optical disks, optical disks (e.g., CD-ROMs, CD-R, CD-RWs, DVD-ROMs, DVD-RAMs, DVD-RWs), magnetic tapes, nonvolatile memory cards, and ROMs. Alternatively, the program code may be downloaded from a server computer or from the cloud via a communications network.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

Not all steps and elements in the above flows and system structure diagrams are necessary, and some steps or elements may be omitted according to actual needs. The execution order of the steps is not fixed, and can be determined as required. The apparatus structures described in the above embodiments may be physical structures or logical structures, that is, some units may be implemented by the same physical entity, or some units may be implemented by a plurality of physical entities, or some units may be implemented by some components in a plurality of independent devices.

The term "exemplary" used throughout this specification means "serving as an example, instance, or illustration," and does not mean "preferred" or "advantageous" over other embodiments. The detailed description includes specific details for the purpose of providing an understanding of the described technology. However, the techniques may be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form in order to avoid obscuring the concepts of the described embodiments.

Although the embodiments of the present disclosure have been described in detail with reference to the accompanying drawings, the embodiments of the present disclosure are not limited to the specific details of the embodiments, and various simple modifications may be made to the technical solutions of the embodiments of the present disclosure within the technical concept of the embodiments of the present disclosure, and all of them fall within the scope of the embodiments of the present disclosure.

The previous description of the contents of the embodiments of the present specification is provided to enable any person skilled in the art to make or use the contents of the embodiments of the present specification. Various modifications to the disclosure of the embodiments herein will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other variations without departing from the scope of the embodiments herein. Thus, the present specification embodiments are not intended to be limited to the examples and designs described herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A data synchronization method for blockchain nodes, comprising:

dividing each data to be synchronized of a first block chain node into a plurality of data sets to be synchronized;

assigning the plurality of sets of data to be synchronized to a plurality of second blockchain nodes;

sending a data synchronization request message to a second block link point corresponding to each data set to be synchronized so as to request to acquire data to be synchronized in the data set to be synchronized; and

and acquiring the data to be synchronized in the corresponding data sets to be synchronized from the second block chain node corresponding to each data set to be synchronized.

2. The data synchronization method of claim 1, wherein the dividing of the respective data to be synchronized of the first blockchain node into the plurality of data sets to be synchronized comprises:

and dividing each data to be synchronized into a plurality of data sets to be synchronized based on the block chain link point list information in the block chain system.

3. The data synchronization method of claim 1, wherein the dividing of each data to be synchronized into a plurality of data sets to be synchronized comprises:

acquiring load information of the plurality of second block chain nodes; and

partitioning each data to be synchronized into a plurality of data sets to be synchronized based on load information of the plurality of second blockchain nodes.

4. The data synchronization method of claim 1, wherein after transmitting a data synchronization request message to a second chunk link point corresponding to each set of data to be synchronized, the method further comprises:

and adjusting each data set to be synchronized based on the response result of the second block chain node corresponding to the each data set to be synchronized to the corresponding data synchronization request message.

5. The data synchronization method of claim 4, wherein the response result comprises:

the response speed of the second block link point to the corresponding data synchronization request message; and/or

The amount of data to be synchronized received from the second blockchain node.

6. The data synchronization method of claim 1, wherein the respective data to be synchronized comprises data of a block to be synchronized.

7. A data synchronization apparatus for blockchain nodes, comprising:

the data to be synchronized dividing unit is used for dividing each data to be synchronized of the first block chain node into a plurality of data sets to be synchronized;

the data to be synchronized distribution unit is used for distributing the data sets to be synchronized to a plurality of second block chain nodes;

the data synchronization request sending unit is used for sending a data synchronization request message to the second block chain nodes corresponding to each data set to be synchronized so as to request to acquire the data to be synchronized in the data set to be synchronized; and

and the data to be synchronized acquiring unit acquires the data to be synchronized in the corresponding data sets to be synchronized from the chain link points of the second blocks corresponding to the data sets to be synchronized.

8. The data synchronization device according to claim 7, wherein the data to be synchronized dividing unit divides each data to be synchronized into a plurality of data sets to be synchronized based on the block chain link point list information in the block chain system.

9. The data synchronization apparatus of claim 7, wherein the data to be synchronized split unit comprises:

the load information acquisition module is used for acquiring the load information of the plurality of second block chain nodes; and

and the data to be synchronized dividing module is used for dividing each data to be synchronized into a plurality of data sets to be synchronized based on the load information of the plurality of second block chain nodes.

10. The data synchronization apparatus of claim 7, further comprising:

and the data sets to be synchronized adjusting unit is used for adjusting each data set to be synchronized based on the response result of the second block chain node corresponding to each data set to be synchronized to the corresponding data synchronization request message after the data synchronization request message is sent to the second block chain node corresponding to each data set to be synchronized.

11. A computing device, comprising:

at least one processor; and

a memory storing instructions that, when executed by the at least one processor, cause the at least one processor to perform the method of any of claims 1 to 6.

12. A non-transitory machine-readable storage medium storing executable instructions that, when executed, cause the machine to perform the method of any of claims 1-6.