Data synchronization method and device, storage medium and electronic equipment

Abstract

The embodiment of the invention discloses a method and a device for realizing data synchronization among multiple nodes based on a block chain, a storage medium and electronic equipment, when a target node on the block chain receives block data sent by a first node, the stored data stored by the target node is firstly updated, and then the data is compared with other adjacent nodes, so that the data synchronization among the multiple nodes is realized. The data of the adjacent nodes are synchronized to be consistent with the data of the target node, and even the data of other nodes of the block chain are synchronized to be consistent.

Description

Technical Field

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

[0002] As the financial investment market becomes increasingly active, the pace of fund data updates is accelerating amidst frequent trading activities. Therefore, to ensure that trading participants can keep up with changes in fund data, it is necessary to synchronize the constantly changing fund data among multiple trading participants in a timely manner.

[0003] In the current fund management system, fund data is primarily shared and synchronized among various trading participants through methods such as files or data sharing tools. However, in practice, it has been found that this method of fund data synchronization largely relies on manual monitoring and management, and often results in significant time delays when sharing and synchronizing fund data, thus greatly reducing the real-time performance of fund data sharing and synchronization. Summary of the Invention

[0004] This specification provides a data synchronization method, apparatus, storage medium, and electronic device, which can prevent the data synchronization of other nodes in the blockchain from being affected by the fault of a single node, thereby improving the success rate of data synchronization. The technical solution is as follows: Firstly, embodiments of this specification provide a data synchronization method, the method comprising: Receive block data sent from a first node, wherein the blockchain includes the first node; The stored first data is updated based on the block data to obtain the second data; The data is compared with the data stored in at least one adjacent second node, and the second data is updated according to the comparison results until the target data is obtained, which is consistent with the data stored in each second node.

[0005] Secondly, embodiments of this specification provide a data synchronization device, the device comprising: A data receiving module is used to receive block data sent from a first node, wherein the blockchain includes the first node; The data update module is used to update the stored first data based on the block data to obtain the second data; The data synchronization module is used to compare the data stored with the data stored in at least one adjacent second node, and update the second data according to the comparison results until the target data is obtained, wherein the target data is consistent with the data stored in each second node.

[0006] Thirdly, embodiments of this specification provide a computer storage medium storing a plurality of instructions adapted for loading by a processor and executing the above-described method steps.

[0007] Fourthly, embodiments of this specification provide a computer program product that stores multiple instructions adapted for loading by a processor and executing the above-described method steps.

[0008] Fifthly, embodiments of this specification provide an electronic device that may include: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to execute the above-described method steps.

[0009] The beneficial effects of the technical solutions provided in some embodiments of this specification include at least the following: This specification proposes a method for data synchronization between multiple nodes based on blockchain. When a target node on the blockchain receives block data sent by the first node, it first updates the data stored in the target node, and then compares the data with other adjacent nodes to synchronize the data of adjacent nodes to be consistent with the data of the target node, and even to synchronize the data of other nodes in the blockchain. This method can achieve eventual consistency of data under multiple nodes without causing exponential expansion of data volume due to data exchange between multiple nodes, and solves the problem that other nodes cannot synchronize data when a single node loses data, thus improving the disaster recovery capability of a single node. Due to the immutable nature of blockchain, the authority of block data from the first node is guaranteed, thereby making the data synchronization method of synchronizing the block data of the first node from the target node to other nodes highly reliable and stable. Attached Figure Description

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

[0011] Figure 1 is a schematic diagram of the architecture of a data synchronization method provided in an embodiment of this specification; Figure 2 is a schematic diagram of the architecture of another data synchronization method provided in the embodiments of this specification; Figure 3 is a schematic diagram of the architecture of another data synchronization method provided in the embodiments of this specification; Figure 4 This is a flowchart illustrating a data synchronization method provided in an embodiment of this specification; Figure 5 is a schematic diagram of a process for receiving block data sent by a first node according to an embodiment of this specification; Figure 6 is a schematic diagram of the structure of block data provided in an embodiment of this specification; Figure 7 is a schematic diagram of the structure of a target node including multiple blocks of data provided in an embodiment of this specification; Figure 8 is a flowchart illustrating another data synchronization method provided in the embodiments of this specification; Figure 9 is a schematic flowchart of a data comparison provided in an embodiment of this specification; Figure 10 is a schematic diagram of a data synchronization device provided in an embodiment of this specification; Figure 11 is a schematic diagram of the structure of an electronic device provided in an embodiment of this specification. Detailed Implementation

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

[0013] In the description of this specification, it should be understood that the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. In the description of this specification, it should be noted that, unless otherwise expressly specified and limited, "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices. Those skilled in the art can understand the specific meaning of the above terms in this specification based on the specific circumstances. Furthermore, in the description of this specification, unless otherwise stated, "multiple" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0014] The present specification will now be described in detail with reference to specific embodiments.

[0015] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in the embodiments of this specification are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the object characteristics, interactive behavior characteristics, and user information involved in this specification were all obtained under full authorization.

[0016] Data synchronization can be understood as the process by which data stored on multiple nodes within the same system or structure achieves eventual consistency. Taking transactional data as an example, with multiple nodes corresponding to transaction participants, Figure 1 illustrates the architecture of a data synchronization method provided in this embodiment. It includes a main transaction terminal 101 and multiple sub-transaction terminals 102, including sub-transaction terminals 1021, 1022, 1023, 1024, 1025, and 1026. It should be understood that the number of sub-transaction terminals shown in Figure 1 is merely illustrative, and this embodiment does not impose any limitations on this number.

[0017] Taking the transaction participants corresponding to multiple nodes as fund-related institutions as an example, these can specifically include sales systems (e.g., sales outlets, individual users, and other third-party sales systems), fund systems, and share registration systems (e.g., open-ended fund registration and transfer systems). For example, the following description uses the fund institution as the main transaction terminal, the fund distributor as the sub-transaction terminal, and the fund data as the transaction data.

[0018] Fund data can include user data, transaction data, asset data, and fund product data. User data includes account opening, account closing, changes in customer information, and account registration data. Transaction data includes subscription, purchase, redemption, transfer of custody, fund conversion, non-trading transfer, share freeze / unfreeze, and forced increase / decrease data. Asset data includes custodian fund assets and user asset data. Fund product data includes product establishment, product issuance, temporary opening of products, product liquidation, and product dividend data.

[0019] As of 2021, the number of domestic fund management companies had reached 137, the number of public funds had reached 9,152, and the number of fund distributors had exceeded 400. With the rapid growth in the number of funds and related institutions, the demand for efficient and synchronized updates of fund information between fund companies and fund distributors has also increased. Users expect to see more timely and authoritative fund net asset value data through fund distributors, while fund distributors also hope to quickly synchronize fund data for subsequent calculations, processing, and display.

[0020] Therefore, in 2004, the China Securities Regulatory Commission (CSRC) formulated a data exchange protocol for open-ended fund business. This protocol established that the data exchange standard between fund distributors and fund institutions was based on the CSRC-standardized TXT interface. The 07 document is a document based on this standard, primarily containing dynamic fund information and fund data. When fund institution 101 publishes the 07 document, multiple fund distributors 102 receive the 07 document containing fund data through their respective links, parse the fund data from the 07 document, and then store the fund data in the databases of their respective fund distributors 102, thus achieving data synchronization between multiple nodes.

[0021] Based on the data synchronization architecture shown in Figure 1, the current sub-transaction terminal 102 obtains transaction data primarily through the 07 file transmitted by the main transaction terminal 101, making it a relatively centralized system. With the main transaction terminal 101 at the center, the 07 file is transmitted to each sub-transaction terminal 102, and each sub-transaction terminal 102 needs its own system to parse the 07 file. However, repeatedly building the parsing system incurs significant costs, and in a centralized transmission architecture, it is easy for a receiving node to malfunction, resulting in transaction data not being updated or being updated incorrectly. This leads to inconsistencies in the transaction data displayed on different sub-transaction terminals 102, i.e., data synchronization failure.

[0022] Therefore, this specification proposes the data synchronization structure shown in Figure 2 in the embodiments to solve the problems caused by the above-mentioned centralized data synchronization structure.

[0023] Figure 2 shows a schematic diagram of the architecture of a data synchronization method proposed in an embodiment of this specification. It includes multiple decentralized nodes, at least nodes 201, 202, 203, 204, 205, 206, 207, and 208. It is understood that the number of nodes and their adjacency relationships shown in this embodiment are merely illustrative, and this specification does not impose any limitations on them. It also includes any other number of nodes and the adjacency relationships between multiple nodes.

[0024] In this embodiment, multiple nodes are set up on a blockchain, which is a decentralized distributed database characterized by being collectively maintained by multiple nodes that have joined the blockchain. Each node stores data blocks arranged in chronological order, and each block contains several data entries. Cryptographic methods are used to ensure the immutability, unforgeability, and verifiability of the data in the blocks. A consensus algorithm enables all nodes on the entire blockchain (theoretically all nodes) to recognize the blocks. Furthermore, different nodes exchange data through a peer-to-peer (P2P) network.

[0025] Specifically, as shown in Figure 3, which is a schematic diagram of the architecture of another data synchronization method provided in the embodiments of this specification, taking nodes as transaction participants and data as transaction data as an example, the nodes correspond to the main transaction terminal or the sub-transaction terminal respectively. Node 201 corresponds to the main transaction terminal 3011, node 203 corresponds to the sub-transaction terminal 301, node 204 corresponds to the sub-transaction terminal 3022, node 205 corresponds to the main transaction terminal 3012, and node 206 corresponds to the sub-transaction terminal 3023. Node 201 is adjacent to nodes 202 and 207 respectively, node 202 is adjacent to nodes 203 and 204 respectively, node 204 is adjacent to node 205, node 205 is adjacent to node 206, node 206 is adjacent to node 207, and node 207 is adjacent to node 208.

[0026] When the main transaction terminal 3011 of node 201 needs to issue transaction data, it sends the transaction data to nodes 202, 204, 205 and 207 that have signed an agreement with node 201, and further synchronizes the transaction data to other nodes in the blockchain through nodes 202, 204, 205 and 207.

[0027] Specifically, such as Figure 4 The diagram shown is a flowchart illustrating a data synchronization method proposed in an embodiment of this specification. This method can be implemented using a computer program and can run on a data synchronization device based on the von Neumann architecture. The computer program can be integrated into an application or run as a standalone utility application.

[0028] Specifically, the data synchronization method includes: S102, Receive block data sent from the first node.

[0029] A consortium blockchain can be formed by selecting a number of specific nodes. A consortium blockchain is a blockchain whose consensus process is controlled by pre-selected nodes. Only nodes belonging to the consortium's transaction members have the right to access it. When a node in the consortium blockchain changes data, it broadcasts the changed data to the entire consortium blockchain. For example, nodes 201 to 208 in Figure 3 form a consortium blockchain.

[0030] Nodes forming a consortium blockchain can negotiate and confirm the rules for joining the blockchain. For example, as shown in Figure 3, multiple master transaction terminals and sub-transaction terminals join the consortium blockchain through negotiation and confirmation. Optionally, a specified consortium blockchain node identifier can be attached to each node in the consortium blockchain, or a digital certificate can be generated to verify the identity of the consortium blockchain node.

[0031] In one embodiment, before receiving block data from the first node, the following steps may be included: An institution joins the consortium blockchain via a protocol, becoming a node in the consortium blockchain, and this node carries consortium blockchain node identification information and / or digital certificate information. When the first node sends block data, and the target node receives the block data, the target node determines whether the consortium blockchain node identification information and / or digital certificate information of the first node (as the node to be verified) matches the consortium blockchain node identification information and / or digital certificate information of the target node. If they match, the first node (as the node to be verified) is determined to be a consortium blockchain node, and verification or recording operations on updated data and even synchronized data are performed. If they do not match, the first node (as the node to be verified) is determined not to be a consortium blockchain node, and no further processing operations on updated data and even synchronized data are performed.

[0032] In this embodiment, by using a consortium blockchain jointly operated by several specific nodes, it is possible to ensure that only authorized nodes in the consortium blockchain can access the shared data in the consortium blockchain, thereby avoiding the privacy leakage problem of nodes and improving the efficiency of data processing.

[0033] In another embodiment, after receiving block data sent from the first node, the following steps may be included: verifying whether the first node is the node corresponding to the target organization; if the first node is the node corresponding to the target organization, updating the stored first data based on the block data to obtain the second data.

[0034] As shown in Figure 5, which is a flowchart illustrating a process for receiving block data sent by a first node according to an embodiment of this specification, the target institution can be an authoritative organization sending the data, such as the main transaction data publishing agency. Specifically, taking the main transaction data publishing agency as the first node 501 as an example, the main transaction data publishing agency 501 encrypts the transaction data using the first encryption parameter corresponding to the stored transaction data type, signs the encrypted transaction data using the node identifier of the reporting node 501, and writes it into the block data. The first node 501 broadcasts the encrypted and signed block data to the target node 502 in the blockchain.

[0035] The target node 502 receives the encrypted and signed block data by the first node, obtains the node identifier in the encrypted and signed block data, and determines whether the first node 501 corresponding to the block data is the node corresponding to the target organization based on the node identifier. If so, it decrypts the encrypted and signed block data by the first node 501 using the stored first decryption parameter.

[0036] In this embodiment, the method for determining whether the first node 501 corresponding to the block data is the node corresponding to the target organization based on the node identifier is as follows: the target node determines whether the first node corresponding to the node identifier can be searched in the stored whitelist based on the node identifier; if so, the first node is determined to be the node corresponding to the target organization; if not, the first node is determined to be the node corresponding to the target organization.

[0037] In this embodiment, in addition to using encryption / decryption parameters to limit the nodes in the blockchain to process data, node identifiers can also be used to identify whether the source node of any data or block data is the node corresponding to the target institution.

[0038] In another embodiment, as shown in Figure 5, each node in the blockchain pre-stores a pair of public and private keys. The private key is used to encrypt the node identifier from plaintext to ciphertext, while the public key is used to decrypt the ciphertext back to plaintext, thereby obtaining the node identifier.

[0039] In this embodiment, the method by which the first node 501 broadcasts the encrypted and signed block data to the blockchain can also be as follows: the first node 501 encrypts the node identifier using a stored key to obtain an encrypted node identifier; the first node 501 broadcasts the encrypted node identifier and the encrypted and signed fund transaction data to the blockchain. The target node 502 receives the encrypted node identifier and the encrypted and signed block data, and identifies the node identifier in the signed block data; the target node 502 decrypts the encrypted node identifier using a stored private key, and determines whether the decrypted node identifier matches the identified node identifier; if they match, the first node 501 corresponding to the node identifier is determined to be the node corresponding to the target institution. Further, the target node 502 obtains the plaintext corresponding to the block data through hash verification and writes the block data into the node block data stored by the target node 502.

[0040] In this embodiment, encrypting block data and node identifiers using public and private keys can prevent node identifiers from being maliciously tampered with, thereby ensuring the integrity of verification information.

[0041] S104. Update the stored first data based on the block data to obtain the second data.

[0042] After the target node obtains the block data sent by the first node, verifies that the operation on the block data is to update the stored first data and performs data synchronization, it updates the stored first data through the block data to obtain the updated second data.

[0043] In a blockchain, the ledger maintained by any node stores data in a connected data block structure. Each data block includes a block header and a block body. The block body stores several data records and a binary Merkle tree composed of the hash values ​​of each record. The block header generally includes a version number and the hash value (hash pointer) of the previous data block connected to this data block. As shown in Figure 6, which is a schematic diagram of a block data structure provided in an embodiment of this specification, it includes at least a hash value, data, a timestamp of data generation, a timestamp of block generation (block version), and a hash pointer (address of the previous block).

[0044] It is understood that the data items in the block header / body and the blockchain structure (e.g., single-chain and dual-chain structures) will vary depending on different application requirements. This embodiment does not impose any restrictions on this, and the block data structure shown in Figure 6 is only for illustration.

[0045] As shown in Figure 7, which is a schematic diagram of the structure of a target node including multiple blocks of data provided in an embodiment of this specification, the first data stored in the target node 600 includes two block data chains composed of multiple blocks of data. That is, multiple blocks of data are connected to their respective blocks through hash pointers corresponding to each block of data. As shown in Figure 7, the first data stored in the target node 600 includes a first block data chain composed of block data 6011, block data 6012, block data 6013, block data 6014, block data 6015, and block data 6016, and a second block data chain composed of block data 6021, block data 6022, block data 6023, and block data 6024. After the target node 700 obtains the block data sent by the first node, it updates the first block data chain consisting of block data 6011, block data 6012, block data 6013, block data 6014, block data 6015, and block data 6016 according to the hash pointer included in the block data, thereby obtaining the updated second data.

[0046] S106. Compare the data stored in at least one adjacent second node with the data stored in the second node, and update the second data according to the comparison results until the target data is obtained.

[0047] In a blockchain, the target node is adjacent to at least one second node. Based on the strategy of modifying first and then reaching consensus, after the target node updates its stored data, it compares it with the data stored by at least one adjacent second node. The comparison determines whether the data stored by the two nodes is the same, and the second node's data is updated based on the comparison result until the target data is obtained. The target data is the data stored in the target node after data synchronization in the blockchain is complete.

[0048] For example, in the architecture diagram shown in Figure 3, the first node 201, which sends block data, sends block data to nodes 202, 204, 205, and 207, which are the target nodes. After updating the first data stored in node 202 according to the block data, node 202 compares the data with the adjacent second nodes 203 and 204. It compares whether the data stored in node 202 and node 203 are the same. If not, it obtains the data stored in node 203. It also compares whether the data stored in node 202 and node 204 are the same. If not, it obtains the data stored in node 204. Nodes 204, 205, and 207 compare the data stored in at least one adjacent second node. They compare whether the data stored in two nodes are the same and update the data stored in each node according to the comparison results until the target data corresponding to each node is obtained. That is, the data of each node in the blockchain reaches final consistency.

[0049] This specification proposes a method for data synchronization between multiple nodes based on blockchain. When a target node on the blockchain receives block data sent by the first node, it first updates the data stored in the target node, and then compares the data with other adjacent nodes to synchronize the data of adjacent nodes to be consistent with the data of the target node, and even to synchronize the data of other nodes in the blockchain. This method can achieve eventual consistency of data under multiple nodes without causing exponential expansion of data volume due to data exchange between multiple nodes, and solves the problem that other nodes cannot synchronize data when a single node loses data, thus improving the disaster recovery capability of a single node. Due to the immutable nature of blockchain, the authority of block data from the first node is guaranteed, thereby making the data synchronization method of synchronizing the block data of the first node from the target node to other nodes highly reliable and stable.

[0050] In one embodiment, as shown in Figure 8, a flowchart of a data synchronization method proposed in this specification is presented. This method can be implemented using a computer program and can run on a data synchronization device based on the von Neumann architecture. The computer program can be integrated into an application or run as a standalone utility application.

[0051] Specifically, the data synchronization method includes: S202, Receive block data sent from the first node.

[0052] See S102 above, which will not be repeated here.

[0053] S204. Update the stored first data based on the block data to obtain the second data.

[0054] See S104 above, which will not be repeated here.

[0055] S206. Obtain the data stored in at least one adjacent second node.

[0056] The target node exchanges data with at least one adjacent second node through a peer-to-peer (P2P) network of the blockchain. Specifically, the target node obtains the block data or data corresponding to the query request by sending a query request to at least one adjacent second node, or the target node broadcasts the second data stored by the target node to at least one adjacent second node.

[0057] In one embodiment, the target node obtains the encrypted and signed block data received by the second node, obtains the node identifier in the encrypted and signed block data, and determines whether the second node corresponding to the block data is a trustworthy node in the blockchain based on the node identifier. If so, it decrypts the encrypted and signed block data using the stored first decryption parameter or private key.

[0058] In this embodiment, the method for determining whether the block data obtained by the target node from the second node is a trustworthy node based on the node identifier is as follows: the target node determines whether the second node corresponding to the node identifier can be found in the stored whitelist based on the node identifier; if so, the second node is determined to be a trustworthy node; if not, the second node is determined to be a non-trustworthy node.

[0059] In this embodiment, in addition to using encryption / decryption parameters to limit the nodes in the blockchain to process data, node identifiers can also be used to identify whether the source node of any data or block data is a trustworthy node.

[0060] S208. Determine whether the data stored in each second node is consistent with the second data.

[0061] After the target node obtains the data stored by the second node, it determines whether the data stored by each second node is consistent with the data stored by the target node. In a blockchain, the ledger maintained by any node stores data in a connected data block structure. Each data block includes a block header and a block body. The block body stores several data records and a binary Merkle tree composed of the hash values ​​of each record. The block header typically includes a version number and the hash value (hash pointer) of the previous data block connected to this data block.

[0062] In one embodiment, the method for determining whether the data stored by each second node is consistent with the second data is as follows: obtain the timestamp of the latest block data in the data stored by the second node, and determine whether the timestamp of the latest block data in the second data stored by the first node is consistent with the timestamp of the latest block data in the data stored by the second node.

[0063] The timestamp is the timestamp of the transaction data in the generated block data. For example, taking the data as transaction data, when the first node generates block data with transaction data, it writes the timestamp T of obtaining transaction data or settling transaction data into the block data; the target node updates the first data corresponding to the target node based on the block data generated by the first node. The timestamp of the latest block data in the first data is timestamp T. It is further determined whether the timestamp of the latest block data in the data stored by the second node is consistent with the timestamp T.

[0064] In another embodiment, the method for determining whether the data stored by each second node is consistent with the second data is as follows: determine whether the hash value of the latest block data in the data stored by each second node is consistent with the hash value of the latest block data in the second data. As shown in Figure 7, when the target node 600 updates the stored first data based on the newly acquired block data 6017, the block data 6017 in the second data includes the Merkle root hash value corresponding to the block data; obtain the hash value of the latest block data in the data stored by the second node, and determine whether the hash value of the latest block data in the second data stored by the first node is consistent with the hash value of the latest block data in the data stored by the second node.

[0065] S210. Broadcast the second data to the second target node or obtain the data stored in the second target node until the target data is obtained.

[0066] If the data of the second target node is inconsistent with the second data, and the timestamp of the latest block data in the second data is later than the timestamp of the latest block data in the data stored by the second target node, send at least one block data obtained after the target block data in the second data to the second target node, and the timestamp of the target block data in the second data is the same as the timestamp of the latest block data in the data stored by the second target node.

[0067] If the data of the second target node is inconsistent with the second data, and the timestamp of the latest block data in the second data is earlier than the timestamp of the latest block data in the data stored in the second target node, obtain at least one block data after obtaining the target block data in the data stored in the second target node, and the timestamp of the target block data in the data stored in the second target node is the same as the timestamp of the latest block data in the data stored in the second target node.

[0068] Specifically, as shown in Figure 9, which is a schematic diagram of a data comparison process provided in an embodiment of this specification, the target node 600 compares data with an adjacent second node 700. In the second data stored in the target node 600, block data 6017 is the latest acquired block data. It is compared with the corresponding block data 7017 in the second node 700. If the data is consistent, no operation is required. The simultaneously acquired block data 6024 is compared with the latest acquired block data 7023 in the second node 700. By comparing the hash values ​​or timestamps of the two block data, as shown in Figure 9, the timestamp of block data 6024 in the target node 600 is significantly later than the timestamp 7023 of the block data in the second node 700. This means that the second node 700 lacks block data 6024 included in the target node 600. The target node 600 broadcasts block data 6024 to the second node 700, and the second node 700 updates the block data chain composed of block data 7021, block data 7022, and block data 7023 based on block data 6024. In other words, the second node 700 acquires the target data.

[0069] In one embodiment, the target data is compared with the data stored by at least one adjacent second node at a preset time frequency, and updated according to the comparison results until the updated target data matches the data stored by each second node. In other words, multiple nodes in the blockchain periodically exchange and verify block data, that is, they compare data with each other to ensure data consistency between each node. When a comparison between two nodes reveals that one node has missing data, the data stored by that node is retrieved from the other node. The method for comparing data can be by comparing the hash value or timestamp of the block data.

[0070] In another embodiment, when a new node joins a consortium blockchain consisting of multiple nodes, it will also compare its data with that of its neighboring nodes until the data of the newly joined node is consistent with that of its neighboring nodes, that is, data synchronization is achieved.

[0071] This embodiment enables multiple nodes in the blockchain to achieve stable data synchronization with a high synchronization rate by periodically exchanging data between nodes or triggering data exchange under preset conditions.

[0072] This specification proposes a method for data synchronization between multiple nodes based on blockchain. When a target node on the blockchain receives block data sent by the first node, it first updates the data stored in the target node, and then compares the data with other adjacent nodes to synchronize the data of adjacent nodes to be consistent with the data of the target node, and even to synchronize the data of other nodes in the blockchain. This method can achieve eventual consistency of data under multiple nodes without causing exponential expansion of data volume due to data exchange between multiple nodes, and solves the problem that other nodes cannot synchronize data when a single node loses data, thus improving the disaster recovery capability of a single node. Due to the immutable nature of blockchain, the authority of block data from the first node is guaranteed, thereby making the data synchronization method of synchronizing the block data of the first node from the target node to other nodes highly reliable and stable.

[0073] The following are embodiments of the apparatus described in this specification, which can be used to execute the embodiments of the methods described in this specification. For details not disclosed in the apparatus embodiments of this specification, please refer to the embodiments of the methods described in this specification.

[0074] Please refer to Figure 10, which shows a schematic diagram of a data synchronization device provided in an exemplary embodiment of this specification. This data synchronization device can be implemented as all or part of a device through software, hardware, or a combination of both, and is applicable to a target node among multiple nodes on a blockchain. The data synchronization device includes a data receiving module 1001, a data updating module 1002, and a data synchronization module 1003.

[0075] The data receiving module 1001 is used to receive block data sent from the first node, wherein the blockchain includes the first node; Data update module 1002 is used to update the stored first data based on the block data to obtain second data; The data synchronization module 1003 is used to compare the data stored with the data stored in at least one adjacent second node, and update the second data according to the comparison results until the target data is obtained, wherein the target data is consistent with the data stored in each second node.

[0076] In one embodiment, the data synchronization module 1003 includes: A data acquisition unit is used to acquire data stored by at least one adjacent second node. A data judgment unit is used to determine whether the data stored in each second node is consistent with the second data. The data synchronization unit is used to broadcast the second data to the second target node or retrieve the data stored in the second target node if the data of the second target node is inconsistent with the second data, until the target node obtains the target data.

[0077] In one embodiment, the data judgment unit is specifically used to determine whether the timestamp of the latest block data in the data stored by the target node is consistent with the timestamp of the latest block data in the second data.

[0078] In one embodiment, the data synchronization unit is specifically configured to send at least one block of data obtained after the target block of the second data to the second target node if the data of the second target node is inconsistent with the second data, and the timestamp of the latest block data in the second data is later than the timestamp of the latest block data in the data stored by the second target node. The timestamp of the target block data in the second data is the same as the timestamp of the latest block data in the data stored by the second target node.

[0079] In one embodiment, the data synchronization unit is specifically configured to, if there is a discrepancy between the data of the second target node and the second data, and the timestamp of the latest block data in the second data is earlier than the timestamp of the latest block data in the data stored by the second target node, obtain at least one block data obtained after the target block data in the data stored by the second target node, wherein the timestamp of the target block data in the data stored by the second target node is the same as the timestamp of the latest block data in the data stored by the second target node.

[0080] In one embodiment, the data judgment unit is specifically used to determine whether the hash value of the latest block data in the data stored by each of the second nodes is consistent with the hash value of the latest block data in the second data.

[0081] In one embodiment, the data synchronization device includes: The verification node module is used to verify whether the first node is the node corresponding to the target organization; Data update module 1002 includes: The verification update unit is used to update the stored first data based on the block data to obtain the second data if the first node is the node corresponding to the target institution.

[0082] In one embodiment, the data synchronization device includes: The timed update module is used to compare the target data with the data stored in at least one adjacent second node based on a preset time frequency, and update the target data according to the comparison results until the updated target data is consistent with the data stored in each second node.

[0083] This specification proposes a method for data synchronization between multiple nodes based on blockchain. When a target node on the blockchain receives block data sent by the first node, it first updates the data stored in the target node, and then compares the data with other adjacent nodes to synchronize the data of adjacent nodes to be consistent with the data of the target node, and even to synchronize the data of other nodes in the blockchain. This method can achieve eventual consistency of data under multiple nodes without causing exponential expansion of data volume due to data exchange between multiple nodes, and solves the problem that other nodes cannot synchronize data when a single node loses data, thus improving the disaster recovery capability of a single node. Due to the immutable nature of blockchain, the authority of block data from the first node is guaranteed, thereby making the data synchronization method of synchronizing the block data of the first node from the target node to other nodes highly reliable and stable.

[0084] It should be noted that the data synchronization device provided in the above embodiments is only illustrated by the division of the above functional modules when executing the data synchronization method. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the data synchronization device and the data synchronization method embodiments provided in the above embodiments belong to the same concept, and the implementation process is detailed in the method embodiments, which will not be repeated here.

[0085] The example numbers in this specification are for descriptive purposes only and do not represent the superiority or inferiority of the examples.

[0086] This specification also provides a computer storage medium that can store multiple instructions adapted for loading and execution by a processor of the data synchronization method described in the embodiments shown in Figures 1-9 above. For details of the execution process, please refer to the specific description of the embodiments shown in Figures 1-9, which will not be repeated here.

[0087] This specification also provides a computer program product that stores at least one instruction, which is loaded by the processor and executed as described in the data synchronization method of the embodiments shown in Figures 1-9 above. For the specific execution process, please refer to the detailed description of the embodiments shown in Figures 1-9, which will not be repeated here.

[0088] Please refer to Figure 11, which is a schematic diagram of the structure of an electronic device provided in an embodiment of this specification. As shown in Figure 11, the electronic device 1100 may include: at least one processor 1101, at least one network interface 1104, a user interface 1103, a memory 1105, and at least one communication bus 1102.

[0089] The communication bus 1102 is used to realize the connection and communication between these components.

[0090] The user interface 1103 may include a display screen and a camera. Optionally, the user interface 1103 may also include a standard wired interface and a wireless interface.

[0091] The network interface 1104 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0092] The processor 1101 may include one or more processing cores. The processor 1101 connects to various parts of the server 1100 via various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 1105, and by calling data stored in the memory 1105. Optionally, the processor 1101 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 1101 may integrate one or a combination of several of the following: a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), and a modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required for display; and the modem handles wireless communication. It is understood that the modem may also be implemented as a separate chip without being integrated into the processor 1101.

[0093] The memory 1105 may include random access memory (RAM) or read-only memory. Optionally, the memory 1105 may include a non-transitory computer-readable storage medium. The memory 1105 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 1105 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch functionality, sound playback functionality, image playback functionality, etc.), instructions for implementing the various method embodiments described above, etc.; the data storage area may store data involved in the various method embodiments described above, etc. Optionally, the memory 1105 may also be at least one storage device located remotely from the aforementioned processor 1101. As shown in FIG11, the memory 1105, as a computer storage medium, may include an operating system, a network communication module, a user interface module, and a data synchronization application.

[0094] In the electronic device 1100 shown in Figure 11, the user interface 1103 is mainly used to provide an input interface for the user and obtain the user input data; while the processor 1101 can be used to call the data synchronization application stored in the memory 1105, which is suitable for target nodes among multiple nodes on the blockchain, and specifically performs the following operations: Receive block data sent from a first node, wherein the blockchain includes the first node; The stored first data is updated based on the block data to obtain the second data; The data is compared with the data stored in at least one adjacent second node, and the second data is updated according to the comparison results until the target data is obtained, which is consistent with the data stored in each second node.

[0095] In one embodiment, the processor 1101 performs the comparison with the data stored in at least one adjacent second node, and updates the second data according to the comparison results, until the target data is obtained. Specifically, the following steps are performed: Retrieve the data stored in at least one adjacent second node; Determine whether the data stored in each second node is consistent with the second data. If the data of the second target node is inconsistent with the second data, broadcast the second data to the second target node or retrieve the data stored in the second target node until the target node obtains the target data.

[0096] In one embodiment, the processor 1101 performs the step of determining whether the data stored in each second node is consistent with the second data, specifically by: Determine whether the timestamp of the latest block data in the data stored in the target node is consistent with the timestamp of the latest block data in the second data.

[0097] In one embodiment, processor 1101 executes the step of broadcasting the second data to the second target node or retrieving the data stored by the second target node if the data of the second target node is inconsistent with the second data, until the target node obtains the target data. Specifically, the following is executed: If the data of the second target node is inconsistent with the second data, and the timestamp of the latest block data in the second data is later than the timestamp of the latest block data in the data stored by the second target node, send at least one block data obtained after the target block data in the second data to the second target node, wherein the timestamp of the target block data in the second data is the same as the timestamp of the latest block data in the data stored by the second target node.

[0098] In one embodiment, processor 1101 executes the step of broadcasting the second data to the second target node or retrieving the data stored by the second target node if the data of the second target node is inconsistent with the second data, until the target node obtains the target data. Specifically, the following is executed: If the data of the second target node is inconsistent with the second data, and the timestamp of the latest block data in the second data is earlier than the timestamp of the latest block data in the data stored by the second target node, obtain at least one block data after obtaining the target block data in the data stored by the second target node, wherein the timestamp of the target block data in the data stored by the second target node is the same as the timestamp of the latest block data in the data stored by the second target node.

[0099] In one embodiment, the processor 1101 performs the step of determining whether the data stored in each second node is consistent with the second data, specifically by: Determine whether the hash value of the latest block data in the data stored in each of the second nodes is consistent with the hash value of the latest block data in the second data.

[0100] In one embodiment, after the processor 1101 executes the block data received by the target node from the first node, and before updating the stored first data based on the block data to obtain the second data, the following is also executed: Verify whether the first node is the node corresponding to the target organization; Processor 1101 executes the first data update storage based on the block data to obtain the second data, specifically executing: If the first node is the node corresponding to the target organization, the stored first data is updated based on the block data to obtain the second data.

[0101] In one embodiment, the processor 1101 performs the comparison with the data stored in at least one adjacent second node, updates the second data according to the comparison results, and after obtaining the target data, further performs the following: The target data is compared with the data stored in at least one adjacent second node at a preset time frequency, and the target data is updated according to the comparison results until the updated target data is consistent with the data stored in each second node.

[0102] This specification proposes a method for data synchronization between multiple nodes based on blockchain. When a target node on the blockchain receives block data sent by the first node, it first updates the data stored in the target node, and then compares the data with other adjacent nodes to synchronize the data of adjacent nodes to be consistent with the data of the target node, and even to synchronize the data of other nodes in the blockchain. This method can achieve eventual consistency of data under multiple nodes without causing exponential expansion of data volume due to data exchange between multiple nodes, and solves the problem that other nodes cannot synchronize data when a single node loses data, thus improving the disaster recovery capability of a single node. Due to the immutable nature of blockchain, the authority of block data from the first node is guaranteed, thereby making the data synchronization method of synchronizing the block data of the first node from the target node to other nodes highly reliable and stable.

[0103] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory, or random access memory, etc.

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

Claims

1. A data synchronization method applicable to a target node among multiple nodes on a blockchain, the method comprising: Receive block data sent from a first node, wherein the blockchain includes the first node; The stored first data is updated based on the block data to obtain the second data; The data is compared with the data stored in at least one adjacent second node, and the data stored in the second node corresponding to the comparison result indicating inconsistency is updated until the target data is obtained, which is consistent with the data stored in each second node.

2. The method according to claim 1, wherein comparing the data stored with at least one adjacent second node includes: Determine whether the timestamp of the latest block data in the data stored in each of the second nodes is consistent with the timestamp of the latest block data in the second data.

3. The method according to claim 1, wherein comparing the data stored with at least one adjacent second node includes: Determine whether the hash value of the latest block data in the data stored in each of the second nodes is consistent with the hash value of the latest block data in the second data.

4. The method according to claim 1, wherein after the target node receives block data sent from the first node, and before updating the stored first data based on the block data to obtain the second data, the method includes: Verify whether the first node is the node corresponding to the target organization; The process of updating the stored first data based on the block data to obtain the second data includes: If the first node is the node corresponding to the target organization, the stored first data is updated based on the block data to obtain the second data.

5. The method according to claim 4, wherein verifying whether the first node is the node corresponding to the target organization includes: Obtain the node identifier in the encrypted and signed block data of the first node, and determine whether the first node corresponding to the block data is the node corresponding to the target organization based on the node identifier.

6. The method according to claim 1, further comprising, after comparing the data stored with at least one adjacent second node, and updating the second data according to the data stored in the second node corresponding to the comparison result indicating inconsistency, until the target data is obtained: The target data is compared with the data stored in at least one adjacent second node at a preset time frequency, and the target data is updated according to the comparison results until the updated target data is consistent with the data stored in each second node.

7. The method according to claim 1, further comprising, before receiving block data sent from the first node: An organization joins the consortium blockchain through a protocol and becomes a node in the consortium blockchain. The node carries consortium blockchain node identification information and / or digital certificate information. The receiving of block data from the first node includes: Determine whether the consortium blockchain node identification information and / or digital certificate information of the first node to be verified matches the consortium blockchain node identification information and / or digital certificate information of the target node. If a match is found, it is determined that the first node to be verified belongs to the consortium blockchain node, and block data sent from the first node belonging to the consortium blockchain node is received. If there is a mismatch, it is determined that the first node, which is the node to be verified, does not belong to the consortium blockchain node, and the block data sent by the first node, which does not belong to the consortium blockchain node, is rejected.

8. The method according to claim 1, wherein the target node is a newly joined node in the consortium blockchain.

9. A data synchronization device, the device comprising: A data receiving module is used to receive block data sent from a first node, wherein the blockchain includes the first node; The data update module is used to update the stored first data based on the block data to obtain the second data; The data synchronization module is used to compare the data stored with the data stored in at least one adjacent second node, and update the second data according to the data stored in the second node corresponding to the comparison result indicating data inconsistency, until the target data is obtained, and the target data is consistent with the data stored in each second node.

10. A computer storage medium storing a plurality of instructions adapted for loading by a processor and executing the method steps of any one of claims 1 to 8.

11. A computer program product storing a plurality of instructions adapted for loading by a processor and executing the method steps of any one of claims 1 to 8.

12. An electronic device, comprising: A processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and executed the method steps as claimed in any one of claims 1 to 8.

Images