A data synchronization method and device based on blockchain

Abstract

The specification discloses a data synchronization method and device based on blockchain. A data synchronization method based on blockchain is applied to a data synchronization system, wherein the data synchronization system is connected to a blockchain node, and comprises: when a trigger condition for data synchronization is met, obtaining a first storage attribute of each block on the blockchain from the blockchain node; determining whether each block is a non-empty block based on the first storage attribute, and adding business transactions in the blocks determined to be non-empty blocks to a synchronization queue, wherein the non-empty blocks are blocks storing business transactions; and synchronizing the business transactions in the synchronization queue to the business system.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a data synchronization method and device based on blockchain. Background Art

[0002] With the continuous development of blockchain technology, blockchain technology is being applied to more and more fields. In related technologies, there is a need to synchronize the data on the blockchain to the off-chain for related business processing. Based on this, how to improve the speed and efficiency of data synchronization on the blockchain has become the focus of the industry. Summary of the invention

[0003] In view of this, this specification provides a data synchronization method and device based on blockchain.

[0004] Specifically, this specification is implemented through the following technical solutions:

[0005] A data synchronization method based on blockchain is applied to a data synchronization system, wherein the data synchronization system is connected to a blockchain node, and comprises:

[0006] When the triggering condition for data synchronization is met, the first storage attribute of each block on the blockchain is obtained from the blockchain node;

[0007] Determining whether each block is a non-empty block based on the first storage attribute, and adding business transactions in the blocks determined to be non-empty blocks to a synchronization queue, wherein the non-empty blocks are blocks storing business transactions;

[0008] Synchronize business transactions in the synchronization queue to the business system.

[0009] A data synchronization device based on blockchain, comprising:

[0010] The acquisition unit, when the triggering condition of data synchronization is met, obtains the first storage attribute of each block on the blockchain from the blockchain node;

[0011] A determination unit, which determines whether each block is a non-empty block based on the first storage attribute, and adds the business transactions in the blocks determined to be non-empty blocks to a synchronization queue, wherein the non-empty blocks are blocks storing business transactions;

[0012] The synchronization unit synchronizes the business transactions in the synchronization queue to the business system.

[0013] A data synchronization device based on blockchain, comprising:

[0014] processor;

[0015] memory for storing machine-executable instructions;

[0016] Wherein, by reading and executing the machine executable instructions corresponding to the blockchain-based data synchronization logic stored in the memory, the processor is prompted to:

[0017] When the triggering condition for data synchronization is met, the first storage attribute of each block on the blockchain is obtained from the blockchain node;

[0018] Determining whether each block is a non-empty block based on the first storage attribute, and adding business transactions in the blocks determined to be non-empty blocks to a synchronization queue, wherein the non-empty blocks are blocks storing business transactions;

[0019] Synchronize business transactions in the synchronization queue to the business system.

[0020] An embodiment of the present specification realizes that when the trigger condition for data synchronization is met, the data synchronization system can obtain the first storage attribute of each block on the blockchain from the blockchain node, determine whether each block is a non-empty block based on the first storage attribute, add the business transactions in the blocks determined to be non-empty blocks to the synchronization queue, and then synchronize the business transactions in the synchronization queue to the business system.

[0021] By adopting the above method, when synchronizing data on the blockchain, non-empty blocks containing business transactions can be determined, and data synchronization is performed only on these non-empty blocks, thereby avoiding data synchronization of empty blocks that do not contain business transactions. Compared with the related technology of fully synchronizing all blocks on the blockchain, data synchronization efficiency can be greatly improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Figure 1 It is a flowchart of a data synchronization method based on blockchain shown in an exemplary embodiment of this specification;

[0023] Figure 2 is a schematic diagram of a blockchain shown in an exemplary embodiment of this specification;

[0024] Figure 3 It is a flowchart of another data synchronization method based on blockchain shown in an exemplary embodiment of this specification;

[0025] Figure 4 This is a hardware structure diagram of an electronic device where a blockchain-based data synchronization device is located, as shown in an exemplary embodiment of this specification;

[0026] Figure 5 It is a block diagram of a data synchronization device based on blockchain shown in an exemplary embodiment of this specification. DETAILED DESCRIPTION

[0027] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementations described in the following exemplary embodiments do not represent all implementations consistent with this specification. Instead, they are merely examples of devices and methods consistent with some aspects of this specification as detailed in the appended claims.

[0028] The terms used in this specification are for the purpose of describing specific embodiments only and are not intended to limit this specification. The singular forms "a", "the" and "the" used in this specification and the appended claims are also intended to include plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0029] It should be understood that although the terms first, second, third, etc. may be used in this specification to describe various information, this information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of this specification, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0030] Blockchain technology, also known as distributed ledger technology, is an emerging technology in which several computing devices jointly participate in "bookkeeping" and jointly maintain a complete distributed database. Blockchain technology has been widely used in many fields because of its decentralized, open and transparent characteristics, each computing device can participate in database records, and data can be quickly synchronized between computing devices.

[0031] In actual application scenarios, there is a need to synchronize the data on the blockchain to the off-chain for related business processing. For example, remittance business can be implemented based on blockchain, and business transactions for implementing remittance can be sent to blockchain nodes. After receiving the transaction, the blockchain node can execute the transaction to update the balance of the accounts of both parties of the remittance. In addition, based on the characteristics of blockchain that it is not easy to be tampered with and consistent, it can ensure that the remittance transaction is safe and reliable. In this scenario, the remittance transaction on the blockchain can be synchronized through the data synchronization system, and the synchronized data can be provided to the business system for subsequent business processing.

[0032] In the related art, the data on the blockchain is usually synchronized in full, that is, each block on the blockchain is synchronized. However, due to the large amount of data stored on the blockchain and not every block stores the data that needs to be synchronized, the full synchronization method will lead to low efficiency.

[0033] Based on this, this specification provides a data synchronization method based on blockchain, which can determine whether each block is an empty block during the data synchronization process, and only synchronize data for non-empty blocks, which can greatly improve data synchronization efficiency compared to full synchronization.

[0034] See also Figure 1 , Figure 1 It is a flowchart of a blockchain-based data synchronization method shown in an exemplary embodiment of this specification. The method can be applied to a data synchronization system, which can specifically be a server or server cluster with a memory and a processor.

[0035] The blockchain-based data synchronization method may include the following steps:

[0036] Step 102, when the triggering condition for data synchronization is met, the first storage attribute of each block on the blockchain is obtained from the blockchain node;

[0037] Step 104, determining whether each block is a non-empty block based on the first storage attribute, and adding the business transactions in the blocks determined to be non-empty blocks to a synchronization queue, wherein the non-empty blocks are blocks storing business transactions;

[0038] Step 106: synchronize the business transactions in the synchronization queue to the business system.

[0039] The above steps are described in detail below.

[0040] In this embodiment, the data synchronization system can be connected to the blockchain node to obtain data from the blockchain node and synchronize it to the business system. Of course, in other embodiments, the data synchronization system and the business system can be the same system, and there is no special limitation on this.

[0041] In this embodiment, trigger conditions for data synchronization may be pre-set. For example, data synchronization may be performed periodically, and the period may be preset, such as every day, every week, etc. The trigger condition may be when the data synchronization period is reached. For another example, it may be determined that the trigger condition for data synchronization is reached after receiving a data synchronization request. A data synchronization request may be initiated according to a specific business scenario. For example, when a business system needs to obtain data on the blockchain for business processing, a data synchronization request may be sent to a data synchronization system. This embodiment does not impose any special restrictions on this.

[0042] In this embodiment, when the triggering condition of data synchronization is met, the data synchronization system can obtain the first storage attribute of each block on the blockchain from any blockchain node, and determine whether each block is a non-empty block based on the first storage attribute. The first storage attribute can be recorded in the world state of the blockchain, which will be described in detail in the following embodiments.

[0043] In this embodiment, blocks that do not store business transactions are determined as empty blocks, and blocks that store business transactions are determined as non-empty blocks, where business transactions are data that need to be synchronized, such as remittance transactions in the aforementioned example, or other types of transactions, which can be set according to specific application scenarios. In addition, it is worth noting that multiple types of transactions may be stored on the block, including business transactions and non-business transactions. This embodiment considers blocks that do not store business transactions to be empty blocks, but it does not mean that there must be no transactions stored on the empty blocks, such as non-business transactions. The method of distinguishing business transactions from non-business transactions can refer to the relevant technology, and this embodiment does not impose any special restrictions on this.

[0044] In this embodiment, the business transactions in the block determined to be a non-empty block can be added to a synchronization queue, which can be stored in a data synchronization system. Then, the business transactions stored in the non-empty block can be synchronized to the business system based on the synchronization queue.

[0045] For example, the identifiers of non-empty blocks can be added to the synchronization queue. When synchronizing business transactions to the business system, the corresponding non-empty blocks can be determined based on these identifiers, and then the business transactions stored on the non-empty blocks can be obtained and synchronized to the business system.

[0046] For another example, all business transactions stored on non-empty blocks may be added to a synchronization queue. When synchronizing the business transactions to a business system, the business transactions may be obtained from the synchronization queue and synchronized to the business system.

[0047] In this embodiment, after the data in the synchronization queue is synchronized, the data in the queue may be cleared.

[0048] As can be seen from the above description, in one embodiment of the present specification, the data synchronization system can obtain the first storage attribute of each block on the blockchain from the blockchain node when the trigger condition for data synchronization is met, determine whether each block is a non-empty block based on the first storage attribute, and add the business transactions in the blocks determined to be non-empty blocks to the synchronization queue, and then synchronize the business transactions in the synchronization queue to the business system.

[0049] By adopting the above method, when synchronizing data on the blockchain, non-empty blocks containing business transactions can be determined, and data synchronization is performed only on these non-empty blocks, thereby avoiding data synchronization of empty blocks that do not contain business transactions. Compared with the related technology of fully synchronizing all blocks on the blockchain, data synchronization efficiency can be greatly improved.

[0050] The following is a description of an embodiment of a method for determining whether each block on a blockchain is a non-empty block based on a first storage attribute provided in this specification.

[0051] 1. The first storage attribute indicates whether the block is a non-empty block

[0052] In one example, starting from the latest block on the blockchain, in order of block height from high to low, based on the first storage attribute of each block, it can be determined whether each block is a non-empty block, and these blocks determined to be non-empty blocks are added to the synchronization queue.

[0053] The following is a specific example. Figure 2 , Figure 2 A blockchain is shown exemplarily, in which there may be several blocks, namely block 1, block 2, ..., block n-4, block n-3, block n-2, block n-1, and block n. Block n is the latest block, and block 1 is the genesis block. Among them, the first storage attribute of "0" represents that the block is an empty block, and the first storage attribute of "1" represents that the block is a non-empty block. Then block 1 is a non-empty block, block 2 is a non-empty block, block n-4 is a non-empty block, block n-3 is a non-empty block, block n-2 is an empty block, block n-1 is an empty block, and block n is a non-empty block.

[0054] Then you can start judging from block n (the latest block). If you find that block n is a non-empty block, you can add block n to the synchronization queue, then judge whether block n-1 is a non-empty block. If you find that block n-1 is an empty block, you will not add it to the synchronization queue. Then judge whether block n-2 is a non-empty block. If you find that block n-2 is an empty block, you will not add it to the synchronization queue… You can judge each block according to the above method until the genesis block (block 1) is judged. Then you can determine that the blocks included in the synchronization queue are: block n, block n-3, block n-4, …, block 2, block 1.

[0055] Of course, although this example describes adding a "block" to the synchronization queue, in fact, only business transactions stored on non-empty blocks can be added to the synchronization queue instead of adding the block itself to the synchronization queue. The following embodiments are similar to this.

[0056] In another example, when determining whether each block is a non-empty block, the empty block may be directly “skipped”.

[0057] It is possible to start from the latest block on the blockchain and determine whether the latest block is a non-empty block according to the first storage attribute corresponding to the latest block.

[0058] If the latest block is a non-empty block, the latest block can be added to the synchronization queue, and it is continued to be determined whether the previous block of the latest block is a non-empty block; if the latest block is an empty block, the latest block is not added to the synchronization queue, and the non-empty block closest to the block height of the latest block can be determined, and the non-empty block is added to the synchronization queue, and it is continued to be determined whether the previous block of the non-empty block is a non-empty block.

[0059] The above method can be used to determine each non-empty block on the blockchain, and these non-empty blocks can be added to the synchronization queue, so as to synchronize the business transactions stored in the non-empty blocks to the business system based on the synchronization queue.

[0060] Still Figure 2 The example shown is used for illustration.

[0061] You can first determine whether block n (the latest block) is a non-empty block. If it is found to be a non-empty block, you can add block n to the synchronization queue, and determine whether the previous block of block n (block n-1) is a non-empty block. If it is found that block n-1 is not a non-empty block, block n-1 will not be added to the synchronization queue, and determine that the non-empty block closest to the block height of block n-1 is block n-3, then block n-3 can be added to the synchronization queue. And determine whether the previous block of block n-3 (block n-4) is a non-empty block. If it is found that block n-4 is a non-empty block, it can be added to the synchronization queue. Then you can determine whether the previous block of block n-4 is a non-empty block, and so on...

[0062] The above method can be used to determine each non-empty block in the blockchain, and add the non-empty block to the synchronization queue. For example, in the above example, the blocks in the synchronization queue include: block n, block n-3, block n-4, ..., block 2, block 1. In addition, the above method can be used to determine the nearest non-empty block n-3 based on block n-1, without judging block n-2, which is equivalent to "skipping" empty blocks, thereby improving efficiency.

[0063] The non-empty block with the closest block height can be determined by the following method. The following is an example of determining the non-empty block with the closest block height to the latest block.

[0064] For example, a blockchain node may also store a second storage attribute (world state), which represents the non-empty block closest to the block height of the current block. When determining the non-empty block closest to the block height of the latest block, the second storage attribute corresponding to the latest block may be obtained, and the closest non-empty block may be determined based on the attribute.

[0065] The recording process of the second storage attribute will be described in detail in the following embodiments.

[0066] 2. The first storage attribute indicates whether the previous block of this block is a non-empty block

[0067] In one example, starting from the latest block on the blockchain, it is possible to determine whether the previous block of the latest block is a non-empty block based on the first storage attribute corresponding to the latest block.

[0068] If the previous block of the latest block is a non-empty block, the previous block of the latest block can be added to the synchronization queue, and continue to determine whether the previous block of the previous block is a non-empty block; if the previous block of the latest block is an empty block, the previous block of the latest block will not be added to the synchronization queue, and continue to determine whether the previous block of the previous block is a non-empty block.

[0069] The above method can be used to determine each non-empty block on the blockchain, and these non-empty blocks can be added to the synchronization queue, so as to synchronize the business transactions stored in the non-empty blocks to the business system based on the synchronization queue.

[0070] Among them, for the latest block, whether it is a non-empty block can be determined according to the method in the aforementioned example, and this embodiment will not be repeated here.

[0071] Still Figure 2 The example shown is used for illustration.

[0072] You can start with block n (the latest block) and determine whether its previous block (block n-1) is a non-empty block according to the second storage attribute corresponding to block n. If it is not a non-empty block, block n-1 will not be added to the synchronization queue, and it will be determined whether the previous block of block n-1 (block n-2) is a non-empty block. If it is found that block n-2 is not a non-empty block, block n-2 will not be added to the synchronization queue, and it will be determined whether the previous block of block n-2 (block n-3) is a non-empty block. If it is found that block n-3 is a non-empty block, block n-3 will be added to the synchronization queue, and it will be determined whether the previous block of block n-3 (block n-4) is an empty block, and so on.

[0073] The above method can be used to determine each non-empty block in the blockchain, and add the non-empty block to the synchronization queue. For example, in the above example, the blocks in the synchronization queue include: block n, block n-3, block n-4, ..., block 2, block 1. The method for determining whether block n is an empty block can refer to the above embodiment.

[0074] In another example, similarly, empty blocks can also be "skipped" during the judgment process.

[0075] It is possible to start from the latest block on the blockchain and determine whether the previous block of the latest block is a non-empty block according to the first storage attribute corresponding to the latest block.

[0076] If the previous block of the latest block is a non-empty block, the previous block of the latest block can be added to the synchronization queue, and it is further determined whether the previous block of the previous block is a non-empty block; if the previous block of the latest block is an empty block, the previous block of the latest block is not added to the synchronization queue, and the non-empty block closest to the block height of the previous block of the latest block can be determined, and the non-empty block is added to the synchronization queue, and it is further determined whether the previous block of the non-empty block is a non-empty block.

[0077] The above method can be used to determine each non-empty block on the blockchain, and these non-empty blocks can be added to the synchronization queue, so as to synchronize the business transactions stored in the non-empty blocks to the business system based on the synchronization queue.

[0078] The method for determining the non-empty block closest to the block height of the previous block of the latest block can refer to the above embodiment. Similarly, for the latest block, it can be determined whether it is a non-empty block according to the method in the above example, which will not be repeated in this embodiment.

[0079] Still Figure 2 The example shown is used for illustration.

[0080] You can start with block n (the latest block) and determine whether its previous block (block n-1) is a non-empty block based on the second storage attribute corresponding to block n. If it is an empty block, block n-1 will not be added to the synchronization queue, and it is determined that the non-empty block closest to the block height of block n-1 is block n-3. Then, block n-3 will be added to the synchronization queue, and it will be determined whether the previous block of block n-3 (block n-4) is an empty block. If block n-4 is not an empty block, block n-4 will be added to the synchronization queue, and it will be determined whether the previous block of block n-4 (block n-5) is a non-empty block, and so on.

[0081] The above method can be used to determine each non-empty block in the blockchain, and add the non-empty block to the synchronization queue. For example, in the above example, the blocks in the synchronization queue include: block n, block n-3, block n-4, ..., block 2, block 1. The method for determining whether block n is an empty block can refer to the above embodiment.

[0082] Of course, the above examples are merely illustrative and are not intended to limit this specification.

[0083] It can be seen from the above description that in one embodiment of the present specification, during the data synchronization process, if a block is determined to be an empty block, a non-empty block closest to the block height of the block can also be determined, and then the non-empty block (the business transactions stored on it) is directly added to the synchronization queue without processing the empty blocks contained between the two blocks, which is equivalent to directly "skipping" the empty blocks, which can greatly improve the data synchronization efficiency.

[0084] The following is a description of another embodiment of a blockchain-based data synchronization method provided in this specification.

[0085] In this embodiment, the first storage attribute and the second storage attribute corresponding to each block can be added to the world state of the blockchain to determine whether each block is an empty block or the non-empty block with the closest block height based on these attributes. The following first describes the recording process of these two attributes.

[0086] 1. First storage attribute

[0087] In this embodiment, the first storage attribute corresponding to each block can be set in the world state of the blockchain. The first storage attribute indicates whether the block is an empty block. For example, see Figure 2 When the attribute value is "1", it indicates that the block is a non-empty block. When the attribute value is "0", it indicates that the block is an empty block.

[0088] The first attribute may be generated in the following manner.

[0089] In one example, a blockchain node may receive a business transaction, which may be initiated by a user or by a blockchain platform, without any special restrictions. After receiving the business transaction, the blockchain node may reach a consensus on the business transaction. After the consensus is reached, the business transaction will be stored in the corresponding block, and then the business transaction may be executed. When executing the business transaction, on the one hand, business-related operations may be performed (such as changes to the balances of the accounts of both parties to the remittance), and on the other hand, operations related to the first attribute record may also be performed. Since the block stores business transactions, that is, it is a non-empty block, the first attribute record logic in the smart contract may be called to record the first storage attribute that represents that the block where the business transaction is located is a non-empty block. For example, still using Figure 2 Taking the example shown as an example, assuming that the business transaction is stored in block n, the business transaction can be executed to record the first storage attribute corresponding to block n and set the attribute value to "1".

[0090] Among them, there may be some blocks on the blockchain that do not store business transactions, so it is impossible to record the first storage attribute corresponding to the block by executing business transactions. Then, when judging whether each block is a non-empty block based on the first storage attribute, the block that cannot obtain the corresponding first storage attribute can be determined as an empty block.

[0091] In another example, the blockchain node may also receive a first storage attribute record transaction. Similarly, the first storage attribute record transaction may be initiated by the blockchain platform or other parties, and there is no special restriction on this. After receiving the first storage attribute record transaction, the blockchain node may reach a consensus on the first storage attribute record transaction. After the consensus is reached, the first storage attribute record transaction may be stored in the corresponding block, and then the first storage attribute record transaction may be executed to call the first storage attribute record logic in the smart contract to determine whether the block where the first storage attribute generation transaction is located stores a business transaction. If so, the block is determined to be a non-empty block; if not, the block is determined to be an empty block. The first storage attribute corresponding to the block may then be recorded based on the judgment result.

[0092] The first storage attribute record transaction may be sent periodically, and the sending period may be the same as the period of block formation on the blockchain. For example, the blockchain will generate blocks periodically during consensus, such as generating one block per second, and the sending period of the first storage attribute record transaction may also be per second.

[0093] This method can make each block store the first storage attribute record transaction, so as to record the first storage attribute based on the transaction. This solves the problem in the above example that the business transaction cannot be executed to record the first storage attribute corresponding to the block because the business transaction is not stored in the block.

[0094] Furthermore, in this specification, the above two methods can also be used at the same time, that is, the business transaction can be executed to record the first storage attribute, and the first storage attribute recording transaction can be executed to record the first storage attribute. Furthermore, when both the business transaction and the first storage attribute recording transaction are stored on the block, the result obtained by executing the transaction later can be used to overwrite the result obtained by executing the transaction earlier. Of course, other methods can also be used, and this embodiment does not impose any special restrictions on this.

[0095] In other embodiments, the first storage attribute may also indicate whether the previous block of the current block is an empty block. For example, when the attribute value is "1", it indicates that the previous block of the current block is a non-empty block. When the attribute value is "0", it indicates that the previous block of the current block is an empty block.

[0096] In this case, the first storage attribute may be recorded in the following manner.

[0097] In one example, a blockchain node may receive a business transaction, execute the business transaction to call the first storage attribute recording logic in the smart contract to determine whether the previous block of the block where the business transaction is located stores a business transaction, and record the first storage attribute of the block where the business transaction is located based on the determination result. For details, please refer to the aforementioned embodiment, and this specification will not be repeated here.

[0098] Similarly, there may be some blocks on the blockchain that do not store business transactions, so it is impossible to record the first storage attribute corresponding to the block by executing business transactions. Then, when judging whether each block is a non-empty block based on the first storage attribute, the previous block of the block that cannot obtain the corresponding first storage attribute can be determined as an empty block.

[0099] In another example, the blockchain node may also receive a first storage attribute record transaction. Similarly, there is no special restriction on the initiator of the first storage attribute record transaction. After receiving the first storage attribute record transaction, the blockchain node may reach a consensus on the first storage attribute record transaction. After the consensus is reached, the first storage attribute record transaction may be stored in the corresponding block, and then the first storage attribute record transaction may be executed to call the third storage attribute record logic in the smart contract to determine whether the previous block of the block where the first storage attribute record transaction is located stores a business transaction. If so, the previous block is determined to be a non-empty block; if not, the previous block is determined to be an empty block. Then, the first storage attribute corresponding to the block may be recorded according to the judgment result.

[0100] Similarly, the first storage attribute record transaction may be sent periodically, and the sending period may be the same as the period of block formation on the blockchain.

[0101] With the above method, since consensus is reached on each block in the blockchain in sequence, when executing the first storage attribute record transaction on a block, the previous block should have been consensus-completed. In this case, the result of judging whether the previous block is an empty block by executing the first storage attribute record transaction is accurate, thus avoiding the problem of inaccurate judgment results due to failure to reach consensus on the transaction.

[0102] Of course, the above examples are merely some illustrative examples provided in this specification. In actual applications, other methods can also be used to determine whether each block is an empty block, and this specification does not give examples one by one here.

[0103] 2. Second storage attribute

[0104] In this embodiment, the second storage attribute may represent a non-empty block whose block height is closest to the current block.

[0105] In one example, a blockchain node may receive a business transaction, execute the business transaction to call the second storage attribute recording logic in the smart contract to determine the non-empty block closest to the block height of the block where the business transaction is located, and record the second storage attribute corresponding to the block where the business transaction is located based on the non-empty block. For details, please refer to the aforementioned embodiment, and this specification will not be repeated here.

[0106] In another example, the blockchain node may also receive a second storage attribute record transaction. Similarly, there is no special restriction on the initiator of the second storage attribute record transaction. After receiving the second storage attribute record transaction, the blockchain node may reach a consensus on the second storage attribute record transaction. After the consensus is reached, the second storage attribute record transaction may be stored in the corresponding block, and then the second storage attribute record transaction may be executed to call the second storage attribute generation logic in the smart contract to determine the non-empty block closest to the block height of the block where the second storage attribute record transaction is located, and record the second storage attribute corresponding to the block where the second storage attribute record transaction is located according to the non-empty block.

[0107] Similarly, the second storage attribute record transaction can be sent periodically, and the sending period can also be the same as the period of block formation on the blockchain.

[0108] Of course, the above examples are only some illustrative examples provided in this specification. In actual applications, other methods can also be used to determine the non-empty block closest to the block height, and this specification does not give examples one by one here.

[0109] After explaining the above-mentioned addition of the attributes corresponding to each block in the world state and the method of generating the attributes, the following describes the data synchronization method based on the blockchain.

[0110] See also Figure 3 , Figure 3 It is a flowchart of another data synchronization method based on blockchain shown in an exemplary embodiment of this specification. The method may include the following steps:

[0111] Step 302, determine whether the triggering condition for data synchronization is met. If so, execute step 304.

[0112] In this embodiment, the method for determining whether the triggering condition for data synchronization is met can refer to the above-mentioned embodiment and will not be described in detail here.

[0113] Step 304, obtain the first storage attribute corresponding to the latest block from the blockchain node, and determine whether the latest block is a non-empty block based on the first storage attribute. If not, execute steps 306-308; if yes, execute step 310.

[0114] Step 306, obtaining the second storage attribute corresponding to the latest block from the blockchain node, and determining the non-empty block closest to the block height of the latest block based on the second storage attribute.

[0115] Step 308: Add the non-empty block to the synchronization queue, and determine whether the previous block is a non-empty block based on the first storage attribute corresponding to the previous block of the non-empty block.

[0116] In this embodiment, the latest block on the blockchain node can be processed to determine whether the latest block is a non-empty block. For example, the first storage attribute corresponding to the latest block can be obtained from the blockchain node, and the first storage attribute can indicate whether the block is a non-empty block. Whether the block is non-empty or not is determined based on the first storage attribute. Among them, the method of obtaining the first attribute (world state) from the blockchain can refer to the relevant technology, and this embodiment will not be described one by one here.

[0117] If the latest block is an empty block, the second storage attribute corresponding to the latest block can be obtained from the blockchain node. The second storage attribute can represent the non-empty block closest to the block height of the block. The non-empty block can be determined based on the second storage attribute and added to the synchronization queue.

[0118] In addition, it is also possible to determine whether the previous block of a non-empty block is a non-empty block. For example, the first storage attribute corresponding to the previous empty block can be obtained from the blockchain node to determine whether it is a non-empty block, and if it is a non-empty block, it can be added to the synchronization queue. If it is an empty block, the non-empty block with the closest block height can be obtained and added to the synchronization queue. And so on.

[0119] Step 310: Add the latest block to the synchronization queue, and determine whether the previous block is a non-empty block based on the first storage attribute corresponding to the previous block of the latest block.

[0120] In this embodiment, if the latest block is a non-empty block, the latest empty block can be added to the synchronization queue. And it is determined whether the previous block of the latest empty block is a non-empty block. For example, the first storage attribute corresponding to the previous empty block can be obtained to determine whether it is a non-empty block. If it is a non-empty block, the business transactions stored on it are added to the synchronization queue. If it is an empty block, the non-empty block with the closest block height is obtained, and the business transactions stored on the non-empty block are added to the synchronization queue. And so on.

[0121] Step 312, after determining each non-empty block in the blockchain, synchronize the data on each block in the synchronization queue.

[0122] In this embodiment, the method of the above steps can be used to determine each non-empty block in the blockchain, and the business transactions in these non-empty blocks are added to the synchronization queue. Then, data synchronization is performed on the business transactions stored on each block in the synchronization queue. For details, please refer to the above embodiment, which will not be repeated here.

[0123] In other embodiments, data synchronization on the blockchain may also be performed in batches. For example, a sliding window that can contain a specified number of blocks may be pre-set, such as a sliding window size of 10 blocks, 5 blocks, etc., which may be pre-set, and the sliding window may be used to synchronize data on the blockchain.

[0124] Still Figure 2 Taking the example shown as an example, assuming that the size of the sliding window is 4 blocks, the sliding window can be used to determine block n to block n-3, block n-4 to block n-7, ..., and then data synchronization processing is performed for each sliding window.

[0125] Taking the sliding window corresponding to block n to block n-3 as an example, we can first determine whether block n is an empty block. If it is not an empty block, we will add block n to the synchronization queue, and then continue to determine whether block n-1 is an empty block. If it is an empty block, we will not add it to the synchronization queue, and determine that the nearest non-empty block is block n-3, then add block n-3 to the synchronization queue. And block n-3 is the last block in the sliding window, then we can determine that the sliding window processing is completed, and we can synchronize the data of the synchronization queue corresponding to the sliding window.

[0126] Similarly, other sliding windows can also be processed using the above method. Moreover, each sliding window can be processed in parallel or in series, which can be set according to the actual business scenario.

[0127] From the above description, it can be seen that in one embodiment of the present specification, several attributes can be added to the world state of the blockchain, and based on these attributes, it is determined whether each block is an empty block or the non-empty block with the closest block height. In this way, empty blocks and non-empty blocks can be determined during data synchronization, so that data synchronization can be performed on non-empty blocks without processing all blocks on the blockchain, which can improve the efficiency of data synchronization.

[0128] Corresponding to the aforementioned embodiment of the blockchain-based data synchronization method, this specification also provides an embodiment of a blockchain-based data synchronization device.

[0129] The embodiments of the data synchronization device based on blockchain in this specification can be applied to electronic devices. The device embodiments can be implemented by software, hardware, or a combination of software and hardware. Taking software implementation as an example, as a device in a logical sense, it is formed by the processor of the electronic device in which it is located reading the corresponding computer program instructions in the non-volatile memory into the memory and running them. From the hardware level, if Figure 4 As shown in the figure, it is a hardware structure diagram of the electronic device where the data synchronization device based on the blockchain is located in this manual, except Figure 4 In addition to the processor, memory, network interface, and non-volatile memory shown, the electronic device in which the device in the embodiment is located may also include other hardware according to the actual function of the electronic device, which will not be described in detail.

[0130] Figure 5 It is a block diagram of a data synchronization device based on blockchain shown in an exemplary embodiment of this specification.

[0131] Please refer to Figure 5 The data synchronization device based on blockchain can be applied in the aforementioned Figure 4 The electronic device shown includes: an acquisition unit 510 , a determination unit 520 and a synchronization unit 530 .

[0132] Wherein, the acquisition unit 510, when the triggering condition of data synchronization is met, acquires the first storage attribute of each block on the blockchain from the blockchain node;

[0133] A determination unit 520 determines whether each block is a non-empty block based on the first storage attribute, and adds business transactions in the blocks determined to be non-empty blocks to a synchronization queue, wherein the non-empty blocks are blocks storing business transactions;

[0134] The synchronization unit 530 synchronizes the business transactions in the synchronization queue to the business system.

[0135] Optionally, the first storage attribute indicates whether the block is a non-empty block. When the determining unit 520 determines whether each block is a non-empty block based on the first storage attribute:

[0136] Starting from the latest block, in order from high to low, each block is judged in turn based on the first storage attribute of each block to see whether it is a non-empty block.

[0137] Optionally, the first storage attribute indicates whether the block is a non-empty block. When the determining unit 520 determines whether each block is a non-empty block based on the first storage attribute:

[0138] Determining whether the latest block is a non-empty block based on a first storage attribute corresponding to the latest block;

[0139] If the latest block is a non-empty block, determining whether the previous block of the latest block is a non-empty block;

[0140] If the latest block is an empty block, a non-empty block closest to the block height of the latest block is determined, and it is determined whether the previous block of the non-empty block is a non-empty block.

[0141] Optionally, the process of recording the first storage attribute includes:

[0142] After receiving the business transaction, the blockchain node executes the business transaction to call the first storage attribute record logic in the smart contract to record the first storage attribute that represents that the block where the business transaction is located is a non-empty block.

[0143] Optionally, the process of recording the first storage attribute includes:

[0144] After receiving the first storage attribute record transaction sent periodically, the blockchain node executes the first storage attribute record transaction to call the first storage attribute record logic in the smart contract to determine whether the first storage attribute record transaction stores a business transaction on the block, and records the first storage attribute corresponding to the block where the first storage attribute record transaction is located based on the judgment result.

[0145] Optionally, the blockchain node stores a second storage attribute corresponding to each block, the second storage attribute represents a non-empty block closest to the block height of the current block, and when the determination unit 520 determines the non-empty block closest to the block height of the latest block:

[0146] Obtaining a second storage attribute corresponding to the latest block from the blockchain node;

[0147] A non-empty block closest to the block height of the latest block is determined based on the second storage attribute.

[0148] Optionally, the process of recording the second storage attribute includes:

[0149] After receiving the business transaction, the blockchain node executes the business transaction to call the second storage attribute recording logic in the smart contract to determine the non-empty block closest to the block height of the block where the business transaction is located, and records the second storage attribute corresponding to the block where the business transaction is located based on the non-empty block.

[0150] Optionally, the process of recording the second storage attribute includes:

[0151] After receiving the periodically sent second storage attribute record transaction, the blockchain node executes the second storage attribute record transaction to call the second storage attribute record logic in the smart contract to determine the non-empty block closest to the block height of the block where the second storage attribute update transaction is located, and records the second storage attribute corresponding to the block where the second storage attribute update transaction is located based on the non-empty block.

[0152] Optionally, the first storage attribute indicates whether a previous block of the current block is an empty block. When the determining unit 520 determines whether each block is a non-empty block based on the first storage attribute:

[0153] For the latest block, determining whether a previous block of the latest block is a non-empty block based on the first storage attribute;

[0154] If the previous block is a non-empty block, determining whether the previous block of the previous block is a non-empty block based on the first storage attribute corresponding to the previous block;

[0155] If the previous block is an empty block, a non-empty block closest to the block height of the previous block is determined, and based on the first storage attribute corresponding to the non-empty block, it is determined whether the previous block of the non-empty block is an empty block.

[0156] Optionally, the process of recording the first storage attribute includes:

[0157] After receiving the first storage attribute record transaction sent periodically, the blockchain node executes the first storage attribute record transaction to call the third storage attribute record logic in the smart contract to determine whether the previous block of the block where the first storage attribute record transaction is located stores a business transaction, and generates the first storage attribute corresponding to the block where the first storage attribute record transaction is located based on the judgment result.

[0158] Optional trigger conditions for data synchronization include:

[0159] After receiving a data synchronization request; and / or reaching a data synchronization period.

[0160] The implementation process of the functions and effects of each unit in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, and will not be repeated here.

[0161] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can refer to the partial description of the method embodiments. The device embodiments described above are only schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this specification. Ordinary technicians in this field can understand and implement it without paying creative work.

[0162] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which may be in the form of a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email transceiver, a game console, a tablet computer, a wearable device or a combination of any of these devices.

[0163] Corresponding to the embodiment of the aforementioned blockchain-based data synchronization method, this specification also provides a blockchain-based data synchronization device, which includes: a processor and a memory for storing machine-executable instructions. The processor and the memory are usually connected to each other via an internal bus. In other possible implementations, the device may also include an external interface to enable communication with other devices or components.

[0164] In this embodiment, by reading and executing the machine executable instructions corresponding to the blockchain-based data synchronization logic stored in the memory, the processor is prompted to:

[0165] A data synchronization method based on blockchain is applied to a data synchronization system, wherein the data synchronization system is connected to a blockchain node, and the method comprises:

[0166] When the triggering condition for data synchronization is met, the first storage attribute of each block on the blockchain is obtained from the blockchain node;

[0167] Determining whether each block is a non-empty block based on the first storage attribute, and adding business transactions in the blocks determined to be non-empty blocks to a synchronization queue, wherein the non-empty blocks are blocks storing business transactions;

[0168] Synchronize business transactions in the synchronization queue to the business system.

[0169] Optionally, the first storage attribute indicates whether the block is a non-empty block. When determining whether each block is a non-empty block based on the first storage attribute, the processor is prompted to:

[0170] Starting from the latest block, in order from high to low, each block is judged in turn based on the first storage attribute of each block to see whether it is a non-empty block.

[0171] Optionally, the first storage attribute indicates whether the block is a non-empty block. When determining whether each block is a non-empty block based on the first storage attribute, the processor is prompted to:

[0172] Determining whether the latest block is a non-empty block based on a first storage attribute corresponding to the latest block;

[0173] If the latest block is a non-empty block, determining whether the previous block of the latest block is a non-empty block;

[0174] If the latest block is an empty block, a non-empty block closest to the block height of the latest block is determined, and it is determined whether the previous block of the non-empty block is a non-empty block.

[0175] Optionally, during the recording of the first storage attribute, the processor is prompted to:

[0176] After receiving the business transaction, the blockchain node executes the business transaction to call the first storage attribute record logic in the smart contract to record the first storage attribute that represents that the block where the business transaction is located is a non-empty block.

[0177] Optionally, during the recording of the first storage attribute, the processor is prompted to:

[0178] After receiving the first storage attribute record transaction sent periodically, the blockchain node executes the first storage attribute record transaction to call the first storage attribute record logic in the smart contract to determine whether the first storage attribute record transaction stores a business transaction on the block, and records the first storage attribute corresponding to the block where the first storage attribute record transaction is located based on the judgment result.

[0179] Optionally, the blockchain node stores a second storage attribute corresponding to each block, the second storage attribute representing a non-empty block closest to the block height of the current block, and when determining the non-empty block closest to the block height of the latest block, the processor is prompted to:

[0180] Obtaining a second storage attribute corresponding to the latest block from the blockchain node;

[0181] A non-empty block closest to the block height of the latest block is determined based on the second storage attribute.

[0182] Optionally, during the recording of the second storage attribute, the processor is prompted to:

[0183] After receiving the business transaction, the blockchain node executes the business transaction to call the second storage attribute recording logic in the smart contract to determine the non-empty block closest to the block height of the block where the business transaction is located, and records the second storage attribute corresponding to the block where the business transaction is located based on the non-empty block.

[0184] Optionally, during the recording of the second storage attribute, the processor is prompted to:

[0185] After receiving the periodically sent second storage attribute record transaction, the blockchain node executes the second storage attribute record transaction to call the second storage attribute record logic in the smart contract to determine the non-empty block closest to the block height of the block where the second storage attribute update transaction is located, and records the second storage attribute corresponding to the block where the second storage attribute update transaction is located based on the non-empty block.

[0186] Optionally, the first storage attribute indicates whether a previous block of the current block is an empty block, and when determining whether each block is a non-empty block based on the first storage attribute, the processor is prompted to:

[0187] For the latest block, determining whether a previous block of the latest block is a non-empty block based on the first storage attribute;

[0188] If the previous block is a non-empty block, determining whether the previous block of the previous block is a non-empty block based on the first storage attribute corresponding to the previous block;

[0189] If the previous block is an empty block, a non-empty block closest to the block height of the previous block is determined, and based on the first storage attribute corresponding to the non-empty block, it is determined whether the previous block of the non-empty block is an empty block.

[0190] Optionally, during the recording of the first storage attribute, the processor is prompted to:

[0191] After receiving the first storage attribute record transaction sent periodically, the blockchain node executes the first storage attribute record transaction to call the third storage attribute record logic in the smart contract to determine whether the previous block of the block where the first storage attribute record transaction is located stores a business transaction, and generates the first storage attribute corresponding to the block where the first storage attribute record transaction is located based on the judgment result.

[0192] Optional trigger conditions for data synchronization include:

[0193] After receiving a data synchronization request; and / or reaching a data synchronization period.

[0194] Corresponding to the embodiment of the aforementioned blockchain-based data synchronization method, this specification also provides a computer-readable storage medium, on which a computer program is stored, and when the program is executed by a processor, the following steps are implemented:

[0195] A data synchronization method based on blockchain is applied to a data synchronization system, wherein the data synchronization system is connected to a blockchain node, and the method comprises:

[0196] When the triggering condition for data synchronization is met, the first storage attribute of each block on the blockchain is obtained from the blockchain node;

[0197] Determining whether each block is a non-empty block based on the first storage attribute, and adding business transactions in the blocks determined to be non-empty blocks to a synchronization queue, wherein the non-empty blocks are blocks storing business transactions;

[0198] Synchronize business transactions in the synchronization queue to the business system.

[0199] Optionally, the first storage attribute represents whether the block is a non-empty block, and determining whether each block is a non-empty block based on the first storage attribute includes:

[0200] Starting from the latest block, in order from high to low, each block is judged in turn based on the first storage attribute of each block to see whether it is a non-empty block.

[0201] Optionally, the first storage attribute represents whether the block is a non-empty block, and determining whether each block is a non-empty block based on the first storage attribute includes:

[0202] Determining whether the latest block is a non-empty block based on a first storage attribute corresponding to the latest block;

[0203] If the latest block is a non-empty block, determining whether the previous block of the latest block is a non-empty block;

[0204] If the latest block is an empty block, a non-empty block closest to the block height of the latest block is determined, and it is determined whether the previous block of the non-empty block is a non-empty block.

[0205] Optionally, the process of recording the first storage attribute includes:

[0206] After receiving the business transaction, the blockchain node executes the business transaction to call the first storage attribute record logic in the smart contract to record the first storage attribute that represents that the block where the business transaction is located is a non-empty block.

[0207] Optionally, the process of recording the first storage attribute includes:

[0208] After receiving the first storage attribute record transaction sent periodically, the blockchain node executes the first storage attribute record transaction to call the first storage attribute record logic in the smart contract to determine whether the first storage attribute record transaction stores a business transaction on the block, and records the first storage attribute corresponding to the block where the first storage attribute record transaction is located based on the judgment result.

[0209] Optionally, the blockchain node stores a second storage attribute corresponding to each block, the second storage attribute represents a non-empty block closest to the block height of the current block, and the determining of the non-empty block closest to the block height of the latest block includes:

[0210] Obtaining a second storage attribute corresponding to the latest block from the blockchain node;

[0211] A non-empty block closest to the block height of the latest block is determined based on the second storage attribute.

[0212] Optionally, the process of recording the second storage attribute includes:

[0213] After receiving the business transaction, the blockchain node executes the business transaction to call the second storage attribute recording logic in the smart contract to determine the non-empty block closest to the block height of the block where the business transaction is located, and records the second storage attribute corresponding to the block where the business transaction is located based on the non-empty block.

[0214] Optionally, the process of recording the second storage attribute includes:

[0215] After receiving the periodically sent second storage attribute record transaction, the blockchain node executes the second storage attribute record transaction to call the second storage attribute record logic in the smart contract to determine the non-empty block closest to the block height of the block where the second storage attribute update transaction is located, and records the second storage attribute corresponding to the block where the second storage attribute update transaction is located based on the non-empty block.

[0216] Optionally, the first storage attribute indicates whether a previous block of the current block is an empty block, and determining whether each block is a non-empty block based on the first storage attribute includes:

[0217] For the latest block, determining whether a previous block of the latest block is a non-empty block based on the first storage attribute;

[0218] If the previous block is a non-empty block, determining whether the previous block of the previous block is a non-empty block based on the first storage attribute corresponding to the previous block;

[0219] If the previous block is an empty block, a non-empty block closest to the block height of the previous block is determined, and based on the first storage attribute corresponding to the non-empty block, it is determined whether the previous block of the non-empty block is an empty block.

[0220] Optionally, the process of recording the first storage attribute includes:

[0221] After receiving the first storage attribute record transaction sent periodically, the blockchain node executes the first storage attribute record transaction to call the third storage attribute record logic in the smart contract to determine whether the previous block of the block where the first storage attribute record transaction is located stores a business transaction, and generates the first storage attribute corresponding to the block where the first storage attribute record transaction is located based on the judgment result.

[0222] Optional trigger conditions for data synchronization include:

[0223] After receiving a data synchronization request; and / or reaching a data synchronization period.

[0224] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0225] The above description is only a preferred embodiment of this specification and is not intended to limit this specification. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of this specification should be included in the scope of protection of this specification.

Claims

1. A data synchronization method based on blockchain, applied to a data synchronization system, wherein the data synchronization system is connected to a blockchain node, and the method comprises: When the triggering condition for data synchronization is met, a first storage attribute of each block on the blockchain is obtained from the blockchain node; wherein the first storage attribute is an attribute recorded for each block on the blockchain according to whether a business transaction after consensus is completed is stored in each block; Determine whether each block is a non-empty block based on the first storage attribute, and add the business transactions in the blocks determined to be non-empty blocks to the synchronization queue; wherein the non-empty blocks are blocks storing business transactions after consensus is completed; Synchronize business transactions in the synchronization queue to the business system.

2. According to the method of claim 1, the first storage attribute represents whether the block is a non-empty block, and the determining whether each block is a non-empty block based on the first storage attribute comprises: Starting from the latest block, in order from high to low, each block is judged in turn based on the first storage attribute of each block to see whether it is a non-empty block.

3. According to the method of claim 1, the first storage attribute represents whether the block is a non-empty block, and the determining whether each block is a non-empty block based on the first storage attribute comprises: Determining whether the latest block is a non-empty block based on a first storage attribute corresponding to the latest block; If the latest block is a non-empty block, determining whether the previous block of the latest block is a non-empty block; If the latest block is an empty block, a non-empty block closest to the block height of the latest block is determined, and it is determined whether the previous block of the non-empty block is a non-empty block.

4. According to the method of claim 2 or 3, the process of recording the first storage attribute comprises: After receiving the business transaction, the blockchain node executes the business transaction to call the first storage attribute record logic in the smart contract to record the first storage attribute that represents that the block where the business transaction is located is a non-empty block.

5. According to the method of claim 2 or 3, the process of recording the first storage attribute comprises: After receiving the first storage attribute record transaction sent periodically, the blockchain node executes the first storage attribute record transaction to call the first storage attribute record logic in the smart contract to determine whether the first storage attribute record transaction stores a business transaction on the block, and records the first storage attribute corresponding to the block where the first storage attribute record transaction is located based on the judgment result.

6. According to the method of claim 3, the blockchain node stores a second storage attribute corresponding to each block, the second storage attribute represents a non-empty block closest to the block height of the current block, and the determining of the non-empty block closest to the block height of the latest block includes: Obtaining a second storage attribute corresponding to the latest block from the blockchain node; A non-empty block closest to the block height of the latest block is determined based on the second storage attribute.

7. The method according to claim 6, wherein the recording process of the second storage attribute comprises: After receiving the business transaction, the blockchain node executes the business transaction to call the second storage attribute recording logic in the smart contract to determine the non-empty block closest to the block height of the block where the business transaction is located, and records the second storage attribute corresponding to the block where the business transaction is located based on the non-empty block.

8. The method according to claim 6, wherein the recording process of the second storage attribute comprises: After receiving the periodically sent second storage attribute record transaction, the blockchain node executes the second storage attribute record transaction to call the second storage attribute record logic in the smart contract to determine the non-empty block closest to the block height of the block where the second storage attribute update transaction is located, and records the second storage attribute corresponding to the block where the second storage attribute update transaction is located based on the non-empty block.

9. According to the method of claim 1, the first storage attribute represents whether the previous block of the current block is an empty block, and the determining whether each block is a non-empty block based on the first storage attribute comprises: For the latest block, determining whether a previous block of the latest block is a non-empty block based on the first storage attribute; If the previous block is a non-empty block, determining whether the previous block of the previous block is a non-empty block based on the first storage attribute corresponding to the previous block; If the previous block is an empty block, a non-empty block closest to the block height of the previous block is determined, and based on the first storage attribute corresponding to the non-empty block, it is determined whether the previous block of the non-empty block is an empty block.

10. The method according to claim 9, wherein the process of recording the first storage attribute comprises: After receiving the first storage attribute record transaction sent periodically, the blockchain node executes the first storage attribute record transaction to call the third storage attribute record logic in the smart contract to determine whether the previous block of the block where the first storage attribute record transaction is located stores a business transaction, and generates the first storage attribute corresponding to the block where the first storage attribute record transaction is located based on the judgment result.

11. According to the method of claim 1, the triggering condition of data synchronization comprises: After receiving the data synchronization request; and / or a data synchronization period is reached.

12. A data synchronization device based on blockchain, comprising: An acquisition unit, when a trigger condition for data synchronization is met, acquires a first storage attribute of each block on the blockchain from a blockchain node; wherein the first storage attribute is an attribute recorded for each block on the blockchain according to whether a business transaction after consensus is completed is stored in each block; A determination unit determines whether each block is a non-empty block based on the first storage attribute, and adds the business transactions in the blocks determined to be non-empty blocks to a synchronization queue; wherein the non-empty blocks are blocks storing business transactions after consensus is completed; The synchronization unit synchronizes the business transactions in the synchronization queue to the business system.

13. The device according to claim 12, wherein the first storage attribute represents whether the block is a non-empty block, and when the determination unit determines whether each block is a non-empty block based on the first storage attribute: Starting from the latest block, in order from high to low, each block is judged in turn based on the first storage attribute of each block to see whether it is a non-empty block.

14. The device according to claim 12, wherein the first storage attribute represents whether the block is a non-empty block, and when the determination unit determines whether each block is a non-empty block based on the first storage attribute: Determining whether the latest block is a non-empty block based on a first storage attribute corresponding to the latest block; If the latest block is a non-empty block, determining whether the previous block of the latest block is a non-empty block; If the latest block is an empty block, a non-empty block closest to the block height of the latest block is determined, and it is determined whether the previous block of the non-empty block is a non-empty block.

15. The device according to claim 13 or 14, wherein the process of recording the first storage attribute comprises: After receiving the business transaction, the blockchain node executes the business transaction to call the first storage attribute record logic in the smart contract to record the first storage attribute that represents that the block where the business transaction is located is a non-empty block.

16. The device according to claim 13 or 14, wherein the process of recording the first storage attribute comprises: After receiving the first storage attribute record transaction sent periodically, the blockchain node executes the first storage attribute record transaction to call the first storage attribute record logic in the smart contract to determine whether the first storage attribute record transaction stores a business transaction on the block, and records the first storage attribute corresponding to the block where the first storage attribute record transaction is located based on the judgment result.

17. According to the device of claim 14, the blockchain node stores a second storage attribute corresponding to each block, the second storage attribute represents a non-empty block closest to the block height of the current block, and when the determination unit determines the non-empty block closest to the block height of the latest block: Obtaining a second storage attribute corresponding to the latest block from the blockchain node; A non-empty block closest to the block height of the latest block is determined based on the second storage attribute.

18. The apparatus according to claim 17, wherein the process of recording the second storage attribute comprises: After receiving the business transaction, the blockchain node executes the business transaction to call the second storage attribute recording logic in the smart contract to determine the non-empty block closest to the block height of the block where the business transaction is located, and records the second storage attribute corresponding to the block where the business transaction is located based on the non-empty block.

19. The apparatus according to claim 17, wherein the process of recording the second storage attribute comprises: After receiving the periodically sent second storage attribute record transaction, the blockchain node executes the second storage attribute record transaction to call the second storage attribute record logic in the smart contract to determine the non-empty block closest to the block height of the block where the second storage attribute update transaction is located, and records the second storage attribute corresponding to the block where the second storage attribute update transaction is located based on the non-empty block.

20. The device according to claim 12, wherein the first storage attribute represents whether the previous block of the current block is an empty block, and when the determination unit determines whether each block is a non-empty block based on the first storage attribute: For the latest block, determining whether a previous block of the latest block is a non-empty block based on the first storage attribute; If the previous block is a non-empty block, determining whether the previous block of the previous block is a non-empty block based on the first storage attribute corresponding to the previous block; If the previous block is an empty block, a non-empty block closest to the block height of the previous block is determined, and based on the first storage attribute corresponding to the non-empty block, it is determined whether the previous block of the non-empty block is an empty block.

21. The apparatus according to claim 20, wherein the process of recording the first storage attribute comprises: After receiving the first storage attribute record transaction sent periodically, the blockchain node executes the first storage attribute record transaction to call the third storage attribute record logic in the smart contract to determine whether the previous block of the block where the first storage attribute record transaction is located stores a business transaction, and generates the first storage attribute corresponding to the block where the first storage attribute record transaction is located based on the judgment result.

22. According to the device of claim 12, the triggering condition of data synchronization comprises: After receiving the data synchronization request; and / or a data synchronization period is reached.

23. A data synchronization device based on blockchain, comprising: processor; memory for storing machine-executable instructions; Wherein, by reading and executing the machine executable instructions corresponding to the blockchain-based data synchronization logic stored in the memory, the processor is prompted to: When the triggering condition for data synchronization is met, a first storage attribute of each block on the blockchain is obtained from the blockchain node; wherein the first storage attribute is an attribute recorded for each block on the blockchain according to whether a business transaction after consensus is completed is stored in each block; Determine whether each block is a non-empty block based on the first storage attribute, and add the business transactions in the blocks determined to be non-empty blocks to the synchronization queue; wherein the non-empty blocks are blocks storing business transactions after consensus is completed; Synchronize business transactions in the synchronization queue to the business system.

Images