Block chain local account book data synchronization method and system

Abstract

The invention relates to the technical field of block chains, in particular to a block chain local account book data synchronization method and system. Comprising the following steps: S1, when block checking is carried out on a block chain, storing the positions of checked blocks every time checking is completed, marking the positions as two check points, and respectively writing hash values into the check points; s2, starting the backtracking check of the new block, and when one check point is backtracked, updating the other check point as the mark of the position of the new block; s3, alternately updating the two check points on the block chain; s4, when the block chain is not bifurcated, the two check points are alternately updated; s5, when the block chain is bifurcated, one check point is located in an effective bifurcated chain, and the two check points are updated alternately; and S6, when the block chain is bifurcated and one check point is located in an invalid bifurcated chain, generating a new check point by taking the check point of the main chain as a backtracking end point, and continuously and alternately updating. The front check point and the rear check point are set in the block chain, so that the repeated workload of checking the local account book can be reduced.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a blockchain local account book data synchronization method and system. Background Art

[0002] In the alliance chain environment, chain nodes are divided into consensus nodes and ordinary business nodes. Consensus nodes are usually clusters composed of an odd number of nodes. The nodes in the cluster execute the consensus protocol, and the leader node is responsible for bookkeeping and block generation. Business nodes only need to synchronize book information from the consensus node.

[0003] In order to eliminate data anomalies caused by accidental factors (such as storage and network delays), each business node needs to regularly inventory and verify the local ledger data. The inventory starts from the current block and verifies each block block by block. If the verification fails, the correct block is synchronized to the consensus node. Each block records the hash of the previous block, and the hash can be used to trace back to the previous block for verification until the verification is traced back to the genesis block.

[0004] As the business grows, the height of the chain also continues to grow. If each ledger inventory is traced back to the genesis block, there will be a lot of unnecessary duplication of work.

[0005] In addition, due to network failure or single-machine failure of consensus nodes, the blockchain may fork due to the split-brain problem of the consensus cluster. Although there are usually measures to prevent long forked chains, forks may still exist, further causing inventory difficulties. Summary of the invention

[0006] The present invention provides a blockchain local account book data synchronization method and system, aiming to solve the problem of a large number of repeated calculations in the existing blockchain inventory method.

[0007] The present invention provides a blockchain local account book data synchronization method, comprising the following steps: S1. When counting blocks in the blockchain, each time a count is completed, the position of the counted blocks is saved, and the two counted block positions are marked as two checkpoints, and the hash values ​​of the two corresponding blocks are written at the two checkpoints respectively; S2. Start the backtracking inventory of the new block. When backtracking to one of the checkpoints, update the other checkpoint to the mark of the new block position, and remove the original block position mark corresponding to the other checkpoint; S3. With the extension of the height of the blockchain and multiple inventory checks, the two checkpoints are updated alternately on the blockchain and moved and updated along the height direction of the blockchain extension; S4. When the blockchain is extended without forking, the two checkpoints perform the alternating update operation of step S3; S5. When there is a fork in the blockchain extension, and one of the checkpoints is located on the main chain and the other checkpoint is located on the valid forked chain, the two checkpoints perform the alternating update operation of step S3; S6. When there is a fork in the blockchain extension, and one of the checkpoints is located on the main chain and the other checkpoint is located on an invalid forked chain, a new checkpoint is generated with the checkpoint of the main chain as the backtracking end point, and the alternating update operation of step S3 is continued.

[0008] As a further improvement of the present invention, the step S1 further includes: When the blockchain performs its first block inventory, the first counted block is traced back to the initial genesis block, the position of the initial genesis block is used as the first checkpoint, and the hash value of the initial genesis block is written into the first checkpoint. The position of the first counted block is used as the second checkpoint, and the hash value of the first counted block is written into the second checkpoint.

[0009] As a further improvement of the present invention, step S2 comprises: S21. When starting the next block inventory, the inventory starts from the nth block. When backtracking to the n-1th block, if it is detected that the hash value of the n-1th block is consistent with the hash value of the second checkpoint, the backtracking of the nth block is stopped, and the hash value of the nth block is written to the first checkpoint, and the mark of the first checkpoint is updated to the position of the nth block, and the block inventory of this time ends; S22. When the next block inventory is started, the inventory is started from the n+1th block. When backtracking to the nth block, if it is detected that the hash value of the nth block is consistent with the hash value of the first checkpoint, the backtracking of the n+1th block is stopped, and the hash value of the n+1th block is written to the second checkpoint, and the mark of the second checkpoint is updated to the position of the n+1th block, and the block inventory is ended; n is an integer and n≥2; The step S3 comprises: When the height of the blockchain is extended and inventoried multiple times, steps S21 and S22 are executed in turn so that the positions and hash values ​​of the first checkpoint and the second checkpoint are updated in turn, and they move forward on the chain alternately until they point to the latest inventoried block.

[0010] As a further improvement of the present invention, the specific execution steps of step S3 include: S31. Inventory starts, locates the latest block, obtains the hash value of the latest block, and searches the local node with this hash value. If a specific block is found, it means that the block of this node is valid and the search is successful. If no specific block can be found in the local node according to this hash value, it means that the block is missing in this node and the search fails. S32. If the retrieval fails, re-download the block; S33. If the search is successful, the hash value of the current block is calculated, and the hash value is compared with the hash values ​​in the first checkpoint and the second checkpoint variables in turn. If the hash value of the current block is the same as the hash value of any of the marking variables in the first checkpoint and the second checkpoint, it means that one of the checkpoints that has been counted is encountered, and the hash value of the block at the beginning of this inventory is used to update the marking variable of the other checkpoint, and then return and end this inventory; S34. If the search succeeds and the hash value of this block is different from the values ​​in the first checkpoint and the second checkpoint, the previous inventory block is found through the information in the block header, and steps S31 to S34 are continued to be executed in a loop.

[0011] As a further improvement of the present invention, step S4 specifically includes: S4. In the case that no fork occurs during the blockchain extension, backtrack along the blockchain starting from the latest block, stop when backtracking to the previous checkpoint on the blockchain, and update the latest block to a new checkpoint. The new checkpoint and the previous checkpoint on the blockchain together constitute two new checkpoints.

[0012] As a further improvement of the present invention, step S5 specifically includes: When there is a fork in the blockchain extension process, and one checkpoint is on the main chain and the other checkpoint is on the valid forked chain, the latest block starts to trace back from the valid forked chain and stops when it traces back to the previous checkpoint on the valid forked chain. The latest block is updated to the new checkpoint. This new checkpoint and the previous checkpoint on the valid forked chain together constitute two new checkpoints.

[0013] As a further improvement of the present invention, step S6 specifically includes: When there is a fork in the blockchain extension process, and one checkpoint is on the main chain and the other checkpoint is on an invalid forked chain, the latest block starts to trace back from the valid forked chain and stops when it traces back to the checkpoint of the main chain. The latest block is updated to the new checkpoint. This new checkpoint and the checkpoint of the main chain together constitute two new checkpoints.

[0014] The present invention also provides a blockchain local account book data synchronization system, comprising a blockchain and a plurality of block nodes arranged on the blockchain, and executing: When the blockchain is counting blocks, each time a count is completed, the position of the counted blocks is saved, and the two counted block positions are marked as two checkpoints, and the hash values ​​of the two corresponding blocks are written at the two checkpoints respectively; Start the backtracking inventory of the new block. When backtracking to one of the checkpoints, update the other checkpoint with the mark of the new block position, and remove the original block position mark corresponding to the other checkpoint; As the height of the blockchain is extended and counted multiple times, the two checkpoints are updated alternately on the blockchain and moved along the height direction of the blockchain; When no fork occurs during the blockchain extension, the two checkpoints perform the alternating update operation of step S3; When there is a fork in the blockchain extension, and one checkpoint is on the main chain and the other checkpoint is on the valid forked chain, the two checkpoints perform alternating update operations; When there is a fork in the blockchain extension, and one checkpoint is on the main chain and the other checkpoint is on an invalid forked chain, a new checkpoint is generated with the checkpoint of the main chain as the backtracking end point, and the alternating update operation continues.

[0015] The present invention also provides a storage medium on which a computer program is stored, and when the program is executed by a processor, the blockchain local account book data synchronization method is implemented.

[0016] The present invention also provides a computer device, including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor implements the blockchain local ledger data synchronization method when executing the program.

[0017] The beneficial effects of the present invention are: introducing checkpoints, that is, at the end of each inventory, the inventory-checked positions are saved, two checkpoints before and after the inventory are set on the blockchain, and these two checkpoints are updated in sequence after each inventory, which can optimize the repeated workload of local ledger verification when there is a possibility of blockchain fork. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 It is a flow chart of the blockchain local account book data synchronization method of the present invention; Figure 2 It is a schematic diagram of a blockchain without forking in the present invention; Figure 3 It is a schematic diagram of a blockchain in which a fork occurs in the present invention. DETAILED DESCRIPTION

[0019] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments.

[0020] like Figure 1 As shown, a blockchain local account book data synchronization method of the present invention comprises the following steps: S1. When the blockchain is counting blocks, each time a count is completed, the position of the counted blocks is saved, and the two counted block positions are marked as two checkpoints, and the hash values ​​of the two corresponding blocks are written at the two checkpoints.

[0021] Specifically, step S1 also includes: When the blockchain performs its first block inventory, the first counted block is traced back to the initial genesis block, the position of the initial genesis block is used as the first checkpoint, and the hash value of the initial genesis block is written into the first checkpoint. The position of the first counted block is used as the second checkpoint, and the hash value of the first counted block is written into the second checkpoint.

[0022] By introducing two checkpoints, we only need to trace back to the initial genesis block during the first block inventory, and use the initial genesis block as the first checkpoint to determine the second checkpoint. The subsequent newly counted blocks only need to trace back to the nearest checkpoint before them. There is no need to trace back to the initial genesis block for each new inventory, which greatly reduces the repeated calculation process of the inventory.

[0023] Moreover, the hash values ​​of the corresponding blocks are written into the first checkpoint and the second checkpoint respectively. The uniqueness and immutability of the hash values ​​can effectively guarantee the integrity and security of the checkpoint data. Whether in the normal block extension process or in the face of abnormal situations such as forks, data errors or malicious attacks, the blocks associated with the checkpoints can be accurately identified and verified by the hash values, thereby ensuring the consistency and authenticity of the local ledger data when it is synchronized between different nodes, effectively preventing the risk of data tampering or incorrect synchronization, and laying a solid foundation for the stable operation of the blockchain system and the trusted interaction of data.

[0024] S2. Start the backtracking inventory of the new block. When backtracking to one of the checkpoints, update the other checkpoint to the mark of the new block position, and remove the original block position mark corresponding to the other checkpoint.

[0025] Step S2 includes: S21. When starting the next block inventory, the inventory starts from the nth block. When backtracking to the n-1th block, if it is detected that the hash value of the n-1th block is consistent with the hash value of the second checkpoint, the backtracking of the nth block is stopped, and the hash value of the nth block is written to the first checkpoint, and the mark of the first checkpoint is updated to the position of the nth block, and the block inventory of this time ends; S22. When the next block inventory is started, the inventory is started from the n+1th block. When backtracking to the nth block, if it is detected that the hash value of the nth block is consistent with the hash value of the first checkpoint, the backtracking of the n+1th block is stopped, and the hash value of the n+1th block is written to the second checkpoint, and the mark of the second checkpoint is updated to the position of the n+1th block, and the block inventory is ended; n is an integer and n≥2.

[0026] After the first inventory of the blockchain is completed, a set of first checkpoints and second checkpoints will be generated, and the subsequent newly added inventory blocks will be updated alternately based on the first checkpoints and second checkpoints. When the blockchain is extended normally and there are no abnormal situations such as data errors or malicious attacks in the middle, the first checkpoint can be updated and replaced through step S21, and a new set of second checkpoints and first checkpoints can be formed with the block where the inventory stops; the second checkpoint can be updated and replaced through step S22, and a new set of first checkpoints and second checkpoints can be formed with the block where the inventory stops.

[0027] S3. As the height of the blockchain is extended and counted multiple times, the two checkpoints are updated alternately on the blockchain and moved and updated along the height direction of the blockchain extension.

[0028] Step S3 includes: When the height of the blockchain is extended and multiple inventory is taken, steps S21 and S22 are executed in turn, so that the positions and hash values ​​of the first checkpoint and the second checkpoint are updated in turn, and they move forward alternately on the chain until they point to the latest inventory block. After the first inventory, the subsequent multiple inventory processes can be carried out alternately according to the processes of steps S21 and S22, so that no matter how high the blockchain is extended, when backtracking, only the block corresponding to the previous checkpoint needs to be used as the backtracking stop point, without having to backtrack to a more previous block every time, which greatly reduces the amount of calculation.

[0029] Specifically, the execution process of step S3 includes: S31. Inventory starts, locates the latest block, obtains the hash value of the latest block, and searches the local node with this hash value. If a specific block is found, it means that the block of this node is valid and the search is successful. If no specific block can be found in the local node according to this hash value, it means that the block is missing in this node and the search fails. S32. If the retrieval fails, re-download the block; S33. If the retrieval is successful, the hash value of this block is calculated, and this hash value is compared with the hash values ​​in the first checkpoint and the second checkpoint variables in turn. If the hash value of this block is the same as the hash value of any mark variable in the first checkpoint or the second checkpoint (assuming that the hash value of this block is the same as the hash value of the first checkpoint), it means that one of the checkpoints that has been counted is encountered, and the hash value of the block at the beginning of this inventory is used to update the mark variable of the other checkpoint (according to the assumption, the hash value of the second checkpoint is updated here), and then return and end this inventory.

[0030] S34. If the search succeeds and the hash value of this block is different from the values ​​in the first checkpoint and the second checkpoint, the previous inventory block is found (i.e. backtracking) through the information in the block header, and steps S31 to S34 are continued in a loop.

[0031] The execution process of step S3 is applicable to the three situations mentioned in steps S4 to S6: the situation where no fork occurs in the blockchain extension; the situation where a fork occurs in the blockchain extension, and one of the checkpoints is located on the main chain and the other checkpoint is located on the valid forked chain; the situation where a fork occurs in the blockchain extension, and one of the checkpoints is located on the main chain and the other checkpoint is located on the invalid forked chain.

[0032] S4. When the blockchain is extended without forking, the two checkpoints perform the alternating update operation of step S3.

[0033] like Figure 2 As shown, step S4 specifically includes: S4. In the case that no fork occurs during the blockchain extension, backtrack along the blockchain starting from the latest block, stop when backtracking to the previous checkpoint on the blockchain, and update the latest block to a new checkpoint. The new checkpoint and the previous checkpoint on the blockchain together constitute two new checkpoints.

[0034] In the case that the chain does not fork, assuming that the first inventory is from the current block (height 1000) to the last initial genesis block (height 0), after the inventory is completed, the hash of the genesis block is written into the variable first checkpoint c1, and the hash of the start block (height 1000) of this inventory is written into the second checkpoint c2.

[0035] The next inventory, assuming that the current block height is 2000, will start the inventory from the current block (height 2000). If everything goes well, it will backtrack to the block with height 1000. If it is found that the block (height 1000) is consistent with the value in the second checkpoint c2, the backtracking will stop. Before the end of the inventory, the hash of the block (height 2000) at the beginning of this inventory will be written to the first checkpoint c1. That is, in the next inventory, the backtracking process will stop when it is found that the block value is equal to the first checkpoint c1 value, and at the same time, the block value at the beginning of this inventory will be written to the second checkpoint c2. In this way, the first checkpoint c1 and the second checkpoint c2 values ​​are updated in turn, and the blocks they point to advance alternately on the blockchain.

[0036] S5. When there is a fork in the blockchain extension, and one checkpoint is located on the main chain and the other checkpoint is located on the valid forked chain, the two checkpoints perform the alternating update operation of step S3.

[0037] Step S5 specifically includes: When there is a fork in the blockchain extension process, and one checkpoint is on the main chain and the other checkpoint is on the valid forked chain, the latest block starts to trace back from the valid forked chain and stops when it traces back to the previous checkpoint on the valid forked chain. The latest block is updated to the new checkpoint. This new checkpoint and the previous checkpoint on the valid forked chain together constitute two new checkpoints.

[0038] like Figure 3 As shown in the figure, the forked chain containing solid blocks is a valid forked chain, and the forked chain containing hollow blocks is an invalid forked chain. Assuming that the blockchain is forked into Figure 3 In the situation shown, since the invalid fork chain is an erroneous branch caused by network disconnection or other reasons, it will eventually be abandoned, and the newly generated block will be generated on the valid fork chain and continue to extend to a higher height. Therefore, when one checkpoint is on the main chain and the other checkpoint is on the valid fork chain, there is no checkpoint on the invalid fork chain at this time. Therefore, the checkpoint generation of the valid fork chain and the main chain is similar to that of a blockchain without forks. It is only necessary to trace back to the previous checkpoint where the corresponding block stops, update the latest block to the new checkpoint, and update the two checkpoints alternately on the valid fork chain during the extension and multiple inventory of the blockchain.

[0039] S6. When there is a fork in the blockchain extension, and one of the checkpoints is located on the main chain and the other checkpoint is located on an invalid forked chain, a new checkpoint is generated with the checkpoint of the main chain as the backtracking end point, and the alternating update operation of step S3 is continued.

[0040] like Figure 3 As shown, step S6 specifically includes: When there is a fork in the blockchain extension process, and one checkpoint is on the main chain and the other checkpoint is on an invalid forked chain, the latest block starts to trace back from the valid forked chain and stops when it traces back to the checkpoint of the main chain. The latest block is updated to the new checkpoint. This new checkpoint and the checkpoint of the main chain together constitute two new checkpoints.

[0041] like Figure 3 As shown in the figure, the forked chain containing solid blocks is a valid forked chain, and the forked chain containing hollow blocks is an invalid forked chain. Assuming that the blockchain is forked into Figure 3 In the situation shown in the figure, and the block of the current node is located in one of the forks, that is, on the valid fork chain, the block pointed to by the closest inventory mark c2 to the current block is eventually abandoned, that is, the second checkpoint c2 is located on the invalid fork chain. Then, when the next inventory is taken, when tracing back from the latest block, the second checkpoint c2 will not be encountered and stopped, so it will continue to backtrack until it encounters the block pointed to by another variable first checkpoint c1 and stops. In this way, the block of the current node does not have to be traced back to the genesis block, reducing the amount of calculation when tracing back.

[0042] The key to this method is to set two counted flags on the chain, and update these two flags in sequence after each count. Because the length of the chain fork is limited, the probability that the two checkpoints before and after fall on an invalid forked chain is so low that it can be ignored. This method can optimize the repeated workload of local ledger verification when there is a possibility of blockchain forks.

[0043] The present invention also provides a blockchain local account book data synchronization system, comprising a blockchain and a plurality of block nodes arranged on the blockchain, and executing: When the blockchain is counting blocks, each time a count is completed, the position of the counted blocks is saved, and the two counted block positions are marked as two checkpoints, and the hash values ​​of the two corresponding blocks are written at the two checkpoints respectively; Start the backtracking inventory of the new block. When backtracking to one of the checkpoints, update the other checkpoint with the mark of the new block position, and remove the original block position mark corresponding to the other checkpoint; As the height of the blockchain is extended and counted multiple times, the two checkpoints are updated alternately on the blockchain and moved along the height direction of the blockchain; When no fork occurs during the blockchain extension, the two checkpoints perform the alternating update operation of step S3; When there is a fork in the blockchain extension, and one checkpoint is on the main chain and the other checkpoint is on the valid forked chain, the two checkpoints perform alternating update operations; When there is a fork in the blockchain extension, and one checkpoint is on the main chain and the other checkpoint is on an invalid forked chain, a new checkpoint is generated with the checkpoint of the main chain as the backtracking end point, and the alternating update operation continues.

[0044] The present invention also provides a storage medium on which a computer program is stored, and when the program is executed by a processor, a method for synchronizing blockchain local account book data is implemented.

[0045] The present invention also provides a computer device, including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor implements a blockchain local ledger data synchronization method when executing the program.

[0046] In order to reduce the repeated calculation of inventory as much as possible, the present invention introduces the concept of checkpoints during inventory. At the end of each inventory, the positions that have been counted are saved, which solves part of the repeated calculation work. However, in the scenario of blockchain forks, the checkpoint position may be marked on an invalid fork, resulting in invalid checkpoints. For this reason, two checkpoints are introduced. When tracing the source of the inventory, as long as any checkpoint is encountered, the value of the other checkpoint is updated. The two checkpoints will move alternately to a higher height on the chain with each inventory. In this way, even if a checkpoint is marked on an invalid fork, the amount of calculation for repeated verification can be greatly reduced.

[0047] The above contents are further detailed descriptions of the present invention in combination with specific preferred embodiments, and it cannot be determined that the specific implementation of the present invention is limited to these descriptions. For ordinary technicians in the technical field to which the present invention belongs, several simple deductions or substitutions can be made without departing from the concept of the present invention, which should be regarded as falling within the protection scope of the present invention.

Claims

1. A blockchain local ledger data synchronization method, characterized in that: The following steps are involved: S1. When counting blocks in the blockchain, each time a count is completed, the position of the counted blocks is saved, and the two counted block positions are marked as two checkpoints, and the hash values ​​of the two corresponding blocks are written at the two checkpoints respectively; S2. Start the backtracking inventory of the new block. When backtracking to one of the checkpoints, update the other checkpoint to the mark of the new block position, and remove the original block position mark corresponding to the other checkpoint; S3. With the extension of the height of the blockchain and multiple inventory checks, the two checkpoints are updated alternately on the blockchain and moved and updated along the height direction of the blockchain extension; S4. When the blockchain is extended without forking, the two checkpoints perform the alternating update operation of step S3; S5. When there is a fork in the blockchain extension, and one of the checkpoints is located on the main chain and the other checkpoint is located on the valid forked chain, the two checkpoints perform the alternating update operation of step S3; S6. When there is a fork in the blockchain extension, and one of the checkpoints is located on the main chain and the other checkpoint is located on an invalid forked chain, a new checkpoint is generated with the checkpoint of the main chain as the backtracking end point, and the alternating update operation of step S3 is continued.

2. The blockchain local account data synchronization method according to claim 1, characterized in that: The step S1 further comprises: When the blockchain performs its first block inventory, the first counted block is traced back to the initial genesis block, the position of the initial genesis block is used as the first checkpoint, and the hash value of the initial genesis block is written into the first checkpoint. The position of the first counted block is used as the second checkpoint, and the hash value of the first counted block is written into the second checkpoint.

3. The blockchain local account data synchronization method according to claim 2, characterized in that: The step S2 comprises: S21. When starting the next block inventory, the inventory starts from the nth block. When backtracking to the n-1th block, if it is detected that the hash value of the n-1th block is consistent with the hash value of the second checkpoint, the backtracking of the nth block is stopped, and the hash value of the nth block is written to the first checkpoint, and the mark of the first checkpoint is updated to the position of the nth block, and the block inventory of this time ends; S22. When the next block inventory is started, the inventory is started from the n+1th block. When backtracking to the nth block, if it is detected that the hash value of the nth block is consistent with the hash value of the first checkpoint, the backtracking of the n+1th block is stopped, and the hash value of the n+1th block is written to the second checkpoint, and the mark of the second checkpoint is updated to the position of the n+1th block, and the block inventory is ended; n is an integer and n≥2; The step S3 comprises: When the height of the blockchain is extended and inventoried multiple times, steps S21 and S22 are executed in turn so that the positions and hash values ​​of the first checkpoint and the second checkpoint are updated in turn, and they move forward on the chain alternately until they point to the latest inventoried block.

4. The blockchain local account data synchronization method according to claim 1, characterized in that: The specific execution steps of step S3 include: S31. Inventory starts, locates the latest block, obtains the hash value of the latest block, and searches the local node with this hash value. If a specific block is found, it means that the block of this node is valid and the search is successful. If no specific block can be found in the local node according to this hash value, it means that the block is missing in this node and the search fails. S32. If the retrieval fails, re-download the block; S33. If the search is successful, the hash value of the current block is calculated, and the hash value is compared with the hash values ​​in the first checkpoint and the second checkpoint variables in turn. If the hash value of the current block is the same as the hash value of any of the marking variables in the first checkpoint and the second checkpoint, it means that one of the checkpoints that has been counted is encountered, and the hash value of the block at the beginning of this inventory is used to update the marking variable of the other checkpoint, and then return and end this inventory; S34. If the search succeeds and the hash value of this block is different from the values ​​in the first checkpoint and the second checkpoint, the previous inventory block is found through the information in the block header, and steps S31 to S34 are continued to be executed in a loop.

5. The blockchain local account data synchronization method according to claim 1, characterized in that: The step S4 specifically includes: S4. In the case that no fork occurs during the blockchain extension, backtrack along the blockchain starting from the latest block, stop when backtracking to the previous checkpoint on the blockchain, and update the latest block to a new checkpoint. The new checkpoint and the previous checkpoint on the blockchain together constitute two new checkpoints.

6. The blockchain local account data synchronization method according to claim 1, characterized in that: The step S5 specifically includes: When there is a fork in the blockchain extension process, and one checkpoint is on the main chain and the other checkpoint is on the valid forked chain, the latest block starts to trace back from the valid forked chain and stops when it traces back to the previous checkpoint on the valid forked chain. The latest block is updated to the new checkpoint. This new checkpoint and the previous checkpoint on the valid forked chain together constitute two new checkpoints.

7. The blockchain local account data synchronization method according to claim 1, characterized in that: The step S6 specifically includes: When there is a fork in the blockchain extension process, and one checkpoint is on the main chain and the other checkpoint is on an invalid forked chain, the latest block starts to trace back from the valid forked chain and stops when it traces back to the checkpoint of the main chain. The latest block is updated to the new checkpoint. This new checkpoint and the checkpoint of the main chain together constitute two new checkpoints.

8. A blockchain local ledger data synchronization system, characterized in that: It includes a blockchain and multiple block nodes set on the blockchain, and executes: When the blockchain is counting blocks, each time a count is completed, the position of the counted blocks is saved, and the two counted block positions are marked as two checkpoints, and the hash values ​​of the two corresponding blocks are written at the two checkpoints respectively; Start the backtracking inventory of the new block. When backtracking to one of the checkpoints, update the other checkpoint with the mark of the new block position, and remove the original block position mark corresponding to the other checkpoint; As the height of the blockchain is extended and counted multiple times, the two checkpoints are updated alternately on the blockchain and moved along the height direction of the blockchain; When no fork occurs during the blockchain extension, the two checkpoints perform the alternating update operation of step S3; When there is a fork in the blockchain extension, and one checkpoint is on the main chain and the other checkpoint is on the valid forked chain, the two checkpoints perform alternating update operations; When there is a fork in the blockchain extension, and one checkpoint is on the main chain and the other checkpoint is on an invalid forked chain, a new checkpoint is generated with the checkpoint of the main chain as the backtracking end point, and the alternating update operation continues.

9. A storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the blockchain local ledger data synchronization method described in any one of claims 1 to 7 is implemented.

10. A computer device comprising a storage medium, a processor, and a computer program stored in the storage medium and executable on the processor, characterized in that: When the processor executes the program, the blockchain local ledger data synchronization method described in any one of claims 1 to 7 is implemented.

Images