Blockchain local ledger data synchronization method and system

Abstract

This invention relates to the field of blockchain technology, and particularly to a method and system for synchronizing local ledger data in a blockchain. The method includes the following steps: S1. During block inventory in the blockchain, after each inventory is completed, the positions of the inventoried blocks are saved and marked as two checkpoints, with hash values ​​written to each; S2. A backtracking inventory of new blocks is initiated. When backtracking to one checkpoint, the other checkpoint is updated with the new block's position marker; S3. The two checkpoints are updated alternately on the blockchain; S4. When the blockchain has not forked, the two checkpoints are updated alternately; S5. When the blockchain has forked, and one checkpoint is located on a valid forked chain, the two checkpoints are updated alternately; S6. When the blockchain has forked, and one checkpoint is located on an invalid forked chain, a new checkpoint is generated with the main chain's checkpoint as the backtracking endpoint, and the alternating updates continue. This invention sets two checkpoints before and after the blockchain, reducing the repetitive workload of local ledger verification.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a method and system for synchronizing local blockchain ledger data. Background Technology

[0002] In a consortium blockchain environment, chain nodes are differentiated into consensus nodes and ordinary business nodes. Consensus nodes are typically a cluster of an odd number of nodes. Within this cluster, the nodes execute the consensus protocol, with the leader node responsible for recording transactions and producing blocks. Business nodes only need to synchronize ledger information from the consensus nodes.

[0003] To eliminate data anomalies caused by accidental factors (such as storage and network latency), each business node needs to periodically inventory and verify its local ledger data. The inventory starts from the current block and verifies each block one by one. If the verification fails, the correct block is synchronized to the consensus node. Each block records the hash of the previous block, which can be used to backtrack to the previous block for verification, until the genesis block is reached.

[0004] As the business grows, the height of the chain also increases. If every ledger check goes back to the genesis block for verification, there will be a lot of unnecessary duplication of work.

[0005] In addition, network failures or single-machine failures of consensus nodes may cause the blockchain to fork due to the split-brain problem of the consensus cluster. Although there are usually measures to ensure that long forked chains will not occur, forks may still exist, further making inventory difficult. Summary of the Invention

[0006] This invention provides a method and system for synchronizing local ledger data in a blockchain, aiming to solve the problem of excessive duplicate calculations in existing blockchain inventory methods.

[0007] This invention provides a method for synchronizing local ledger data in a blockchain, comprising the following steps:

[0008] S1. When the blockchain is being inventoried, each time an inventory is completed, the positions of the inventoried blocks are saved, and the two inventoried block positions are marked as two checkpoints. The hash values ​​of the two corresponding blocks are written to the two checkpoints respectively.

[0009] S2. Start the backtracking inventory of the new block. When backtracking to one of the checkpoints, update the other checkpoint with the new block location marker and remove the original block location marker corresponding to the other checkpoint.

[0010] S3. As the height of the blockchain increases and multiple inventory checks are performed, the two checkpoints are updated alternately on the blockchain and move along the direction of the blockchain's height increase.

[0011] S4. If no fork occurs in the blockchain extension, the two checkpoints perform the alternating update operation of step S3;

[0012] 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 fork chain, the two checkpoints perform the alternating update operation of step S3.

[0013] S6. 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 invalid fork chain, the new checkpoint is generated with the checkpoint of the main chain as the backtracking endpoint, and the alternating update operation of step S3 continues to be executed.

[0014] As a further improvement of the present invention, step S1 further includes:

[0015] When the blockchain performs its first block count, the blocks counted are 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 to the first checkpoint. The position of the first block count is used as the second checkpoint, and the hash value of the first block count is written to the second checkpoint.

[0016] As a further improvement of the present invention, step S2 includes:

[0017] S21. When starting the next block count, start counting from block n. When backtracking to block n-1, if the hash value of block n-1 is found to be consistent with the hash value of the second checkpoint, then the backtracking of block n stops, the hash value of block n is written to the first checkpoint, the mark of the first checkpoint is updated to the position of block n, and the block count ends.

[0018] S22. When starting the next block count, begin counting from block (n+1). When backtracking to block (n), if the hash value of block (n) matches the hash value of the first checkpoint, the backtracking of block (n+1) stops, the hash value of block (n+1) is written to the second checkpoint, the mark of the second checkpoint is updated to the position of block (n+1), and the block count ends; n is an integer and n≥2;

[0019] Step S3 includes:

[0020] During the lengthening of the blockchain and multiple inventory checks, steps S21 and S22 are executed alternately to update the position and hash value of the first and second checkpoints in turn, and to move forward alternately on the chain until pointing to the latest inventory block.

[0021] As a further improvement of the present invention, the specific execution steps of step S3 include:

[0022] S31. Inventory begins. Locate the latest block and obtain its hash value. Use this hash value to perform a search on the local node. If a specific block is found, it means the block on this node is valid, and the search is successful. If a specific block cannot be found on the local node based on this hash value, it means the local node is missing the block, and the search fails.

[0023] S32. If the retrieval fails, download the block again;

[0024] S33. If the retrieval is successful, calculate the hash value of this block and compare this hash value with the hash values ​​in the variables of the first checkpoint and the second checkpoint in turn. If the hash value of this block is the same as the hash value of any of the marker variables of the first checkpoint and the second checkpoint, it means that one of the checkpoints that has been inventoried has been encountered. Then, use the hash value of the block at the beginning of this inventory to update the marker variable of the other checkpoint, and then return and end this inventory.

[0025] S34. If the retrieval is successful and the hash value of this block is different from the values ​​in the first checkpoint and the second checkpoint, then the previous inventory block is found through the information in the block header, and steps S31 to S34 are executed in a loop.

[0026] As a further improvement of the present invention, step S4 specifically includes:

[0027] S4. If no fork occurs in the blockchain extension, backtracking is performed from the latest block along the blockchain until the previous checkpoint on the blockchain is reached. The latest block is then updated as the new checkpoint, which together with the previous checkpoint on the blockchain constitutes two new checkpoints.

[0028] As a further improvement of the present invention, step S5 specifically includes:

[0029] When a fork occurs during the extension of a blockchain, and one checkpoint is on the main chain while the other checkpoint is on the valid fork chain, the latest block starts backtracking from the valid fork chain and stops when it reaches the previous checkpoint on the valid fork chain. The latest block is then updated as a new checkpoint, and this new checkpoint, together with the previous checkpoint on the valid fork chain, constitutes two new checkpoints.

[0030] As a further improvement of the present invention, step S6 specifically includes:

[0031] When a fork occurs during the extension of the blockchain, and one checkpoint is located on the main chain while another checkpoint is located on an invalid fork chain, the latest block starts backtracking from the valid fork chain and stops when it reaches the checkpoint on the main chain. This latest block is then updated as the new checkpoint, and this new checkpoint, together with the checkpoint on the main chain, constitutes two new checkpoints.

[0032] This invention also provides a blockchain local ledger data synchronization system, including a blockchain and multiple block nodes set on the blockchain, and performs the following:

[0033] When the blockchain is conducting a block inventory, each time an inventory is completed, the positions of the inventoried blocks are saved, and the two inventoried block positions are marked as two checkpoints. The hash values ​​of the two corresponding blocks are written to the two checkpoints respectively.

[0034] Initiate a backtracking inventory of the new block. When backtracking to one of the checkpoints, update the other checkpoint with the new block location marker and remove the original block location marker corresponding to the other checkpoint.

[0035] As the blockchain lengthens and multiple inventory checks occur, the two checkpoints are updated alternately on the blockchain and move along the length of the blockchain.

[0036] If no fork occurs in the blockchain extension, the two checkpoints perform the alternating update operation of step S3;

[0037] When a blockchain extension has a fork, and one checkpoint is located on the main chain while the other checkpoint is located on the valid fork chain, the two checkpoints perform alternating update operations.

[0038] When a blockchain extension has a fork, and one checkpoint is located on the main chain while the other checkpoint is located on an invalid fork chain, a new checkpoint is generated with the main chain's checkpoint as the backtracking endpoint, and the alternating update operation continues.

[0039] The present invention also provides a storage medium on which a computer program is stored, wherein the program, when executed by a processor, implements the blockchain local ledger data synchronization method.

[0040] 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 executes the program to implement the blockchain local ledger data synchronization method.

[0041] The beneficial effects of this invention are: the introduction of checkpoints, that is, at the end of each inventory count, the counted positions are saved, two checkpoints that have been counted are set on the blockchain, and these two checkpoints are updated sequentially after each inventory count, which can optimize the repetitive workload of local ledger verification in the case of the possibility of blockchain forks. Attached Figure Description

[0042] Figure 1 This is a flowchart of the blockchain local ledger data synchronization method of the present invention;

[0043] Figure 2 This is a schematic diagram of a blockchain in this invention where no forks appear;

[0044] Figure 3 This is a schematic diagram of a blockchain with a fork in this invention. Detailed Implementation

[0045] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments.

[0046] like Figure 1 As shown, a blockchain local ledger data synchronization method of the present invention includes the following steps:

[0047] S1. When the blockchain is being inventoried, each time an inventory is completed, the positions of the inventoried blocks are saved, and the two inventoried block positions are marked as two checkpoints. The hash values ​​of the two corresponding blocks are written to the two checkpoints respectively.

[0048] Specifically, step S1 also includes:

[0049] When the blockchain performs its first block count, the blocks counted are 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 to the first checkpoint. The position of the first block count is used as the second checkpoint, and the hash value of the first block count is written to the second checkpoint.

[0050] By introducing two checkpoints, the first block count only needs to backtrack to the initial genesis block, and the initial genesis block is used as the first checkpoint to determine the second checkpoint. Subsequent new counts only need to backtrack to the nearest checkpoint before it, without having to backtrack to the initial genesis block for each new count, which greatly reduces the redundant calculation process of the count.

[0051] Furthermore, by writing the hash values ​​of the corresponding blocks at the first and second checkpoints, and leveraging the uniqueness and immutability of hash values, the integrity and security of checkpoint data can be effectively guaranteed. Whether during normal block extension processes or in the face of anomalies such as forks, data errors, or malicious attacks, the hash values ​​can be used to accurately identify and verify the blocks associated with the checkpoints. This ensures the consistency and authenticity of local ledger data when synchronized across 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.

[0052] S2. Start backtracking the new block. When backtracking to one of the checkpoints, update the other checkpoint with the new block location marker and remove the original block location marker corresponding to the other checkpoint.

[0053] Step S2 includes:

[0054] S21. When starting the next block count, start counting from block n. When backtracking to block n-1, if the hash value of block n-1 is found to be consistent with the hash value of the second checkpoint, then the backtracking of block n stops, the hash value of block n is written to the first checkpoint, the mark of the first checkpoint is updated to the position of block n, and the block count ends.

[0055] S22. When starting the next block count, begin counting from block (n+1). When backtracking to block (n), if the hash value of block (n) matches the hash value of the first checkpoint, the backtracking of block (n+1) stops, the hash value of block (n+1) is written to the second checkpoint, the mark of the second checkpoint is updated to the position of block (n+1), and the block count ends; n is an integer and n≥2.

[0056] After the initial blockchain inventory is completed, a first checkpoint and a second checkpoint are generated. Subsequent inventory blocks will be updated alternately based on these first and second checkpoints. When the blockchain extends normally and there are no abnormal situations such as data errors or malicious attacks, step S21 can update and replace the first checkpoint, forming a new set of second and first checkpoints with the block at its inventory stop position. Step S22 can update and replace the second checkpoint, forming a new set of first and second checkpoints with the block at its inventory stop position.

[0057] S3. As the blockchain lengthens and multiple inventory checks occur, the two checkpoints are updated alternately on the blockchain and move along the length of the blockchain.

[0058] Step S3 includes:

[0059] During blockchain height extension and multiple inventory checks, steps S21 and S22 are executed alternately to update the positions and hash values ​​of the first and second checkpoints, allowing them to move forward on the chain alternately until they point to the latest inventory block. Based on the initial inventory check, subsequent inventory checks can be performed alternately according to steps S21 and S22. This ensures that no matter how large the blockchain extends, backtracking only requires using the block corresponding to the previous checkpoint as the backtracking stop point, eliminating the need to backtrack to an earlier block each time, significantly reducing computational load.

[0060] Specifically, the execution process of step S3 includes:

[0061] S31. Inventory begins. Locate the latest block and obtain its hash value. Use this hash value to perform a search on the local node. If a specific block is found, it means the block on this node is valid, and the search is successful. If a specific block cannot be found on the local node based on this hash value, it means the local node is missing the block, and the search fails.

[0062] S32. If the retrieval fails, download the block again;

[0063] S33. If the retrieval is successful, calculate the hash value of this block and compare it with the hash values ​​in the variables of the first and second checkpoints in turn. If the hash value of this block is the same as the hash value of any of the marker variables in the first and second checkpoints (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 already been inventoried has been encountered. Then, use the hash value of the block at the beginning of this inventory to update the marker variable of the other checkpoint (according to the assumption, update the hash value of the second checkpoint here), and then return and end this inventory.

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

[0065] The execution process of step S3 is applicable to the three situations mentioned in steps S4 to S6: the blockchain extension does not have a fork; the blockchain extension has a fork, and one checkpoint is located on the main chain, while the other checkpoint is located on the valid fork chain; the blockchain extension has a fork, and one checkpoint is located on the main chain, while the other checkpoint is located on the invalid fork chain.

[0066] S4. If no fork occurs in the blockchain extension, the two checkpoints perform the alternating update operation of step S3.

[0067] like Figure 2 As shown, step S4 specifically includes:

[0068] S4. If no fork occurs in the blockchain extension, backtracking is performed from the latest block along the blockchain until the previous checkpoint on the blockchain is reached. The latest block is then updated as the new checkpoint, which together with the previous checkpoint on the blockchain constitutes two new checkpoints.

[0069] If the chain does not fork, assume that the first inventory count starts from the current block (height 1000) and goes up to the last initial genesis block (height 0). After the inventory count is completed, write the hash of the genesis block to the first checkpoint c1 and write the hash of the starting block of this inventory count (height 1000) to the second checkpoint c2.

[0070] In the next inventory count, assuming the current block height is 2000, the count will begin from the current block (height 2000). If everything is normal, it will backtrack to block height 1000. If this block (height 1000) matches the value in the second checkpoint c2, the backtracking will stop. Before the count ends, the hash of the block (height 2000) from the start of this count will be written to the first checkpoint c1. That is, in the next inventory count, the backtracking process will stop when a block value equals the value of the first checkpoint c1, and simultaneously, the block value from the start of this count will be written to the second checkpoint c2. In this way, the values ​​of the first checkpoint c1 and the second checkpoint c2 are updated alternately, and the blocks they point to advance alternately on the blockchain.

[0071] 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 fork chain, the two checkpoints perform the alternating update operation of step S3.

[0072] Step S5 specifically includes:

[0073] When a fork occurs during the extension of a blockchain, and one checkpoint is on the main chain while the other checkpoint is on the valid fork chain, the latest block starts backtracking from the valid fork chain and stops when it reaches the previous checkpoint on the valid fork chain. The latest block is then updated as a new checkpoint, and this new checkpoint, together with the previous checkpoint on the valid fork chain, constitutes two new checkpoints.

[0074] like Figure 3 As shown in the diagram, forked chains containing solid blocks are valid forked chains, while forked chains containing hollow blocks are invalid forked chains. Assume the blockchain forks as follows: Figure 3 As shown, since invalid forks are erroneous branches caused by network disconnection or other reasons, they will eventually be discarded. Newly generated blocks will be generated on valid forks and continue to extend to higher levels. Therefore, when one checkpoint is on the main chain and another checkpoint is on the valid fork, no checkpoint appears on the invalid fork. Thus, the checkpoint generation of valid forks and the main chain is similar to that of a blockchain without forks. It is only necessary to backtrack to the block corresponding to the previous checkpoint and then update the latest block as the new checkpoint. During the extension of the blockchain and multiple recaps, the two checkpoints on the valid fork are alternately updated.

[0075] S6. 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 invalid fork chain, the new checkpoint is generated with the checkpoint of the main chain as the backtracking endpoint, and the alternating update operation of step S3 continues to be executed.

[0076] like Figure 3 As shown, step S6 specifically includes:

[0077] When a fork occurs during the extension of the blockchain, and one checkpoint is located on the main chain while another checkpoint is located on an invalid fork chain, the latest block starts backtracking from the valid fork chain and stops when it reaches the checkpoint on the main chain. This latest block is then updated as the new checkpoint, and this new checkpoint, together with the checkpoint on the main chain, constitutes two new checkpoints.

[0078] like Figure 3 As shown in the diagram, forked chains containing solid blocks are valid forked chains, while forked chains containing hollow blocks are invalid forked chains. Assume the blockchain forks as follows: Figure 3 In the scenario shown, where the current node's block is located on one of the forks (i.e., on the valid fork chain), the block pointed to by the nearest checkpoint c2 is eventually discarded, meaning the second checkpoint c2 is located on the invalid fork chain. Therefore, during the next checkpoint, when backtracking from the latest block, the second checkpoint c2 will not be encountered and will stop. Instead, backtracking will continue until the block pointed to by the first checkpoint c1 of another variable is encountered and then stopped. In this way, the current node's block does not have to backtrack all the way to the genesis block, reducing the amount of computation during backtracking.

[0079] The key to this method lies in setting two checkpoints on the chain, one before and one after, and updating these two checkpoints sequentially after each check. Because the length of a chain fork is finite, the probability of both checkpoints falling on an invalid fork chain is negligible. This method optimizes the repetitive workload of local ledger checks in situations where there is a possibility of blockchain forks.

[0080] This invention also provides a blockchain local ledger data synchronization system, including a blockchain and multiple block nodes set on the blockchain, and performs the following:

[0081] When the blockchain is conducting a block inventory, each time an inventory is completed, the positions of the inventoried blocks are saved, and the two inventoried block positions are marked as two checkpoints. The hash values ​​of the two corresponding blocks are written to the two checkpoints respectively.

[0082] Initiate a backtracking inventory of the new block. When backtracking to one of the checkpoints, update the other checkpoint with the new block location marker and remove the original block location marker corresponding to the other checkpoint.

[0083] As the blockchain lengthens and multiple inventory checks occur, the two checkpoints are updated alternately on the blockchain and move along the length of the blockchain.

[0084] If no fork occurs in the blockchain extension, the two checkpoints perform the alternating update operation of step S3;

[0085] When a blockchain extension has a fork, and one checkpoint is located on the main chain while the other checkpoint is located on the valid fork chain, the two checkpoints perform alternating update operations.

[0086] When a blockchain extension has a fork, and one checkpoint is located on the main chain while the other checkpoint is located on an invalid fork chain, a new checkpoint is generated with the main chain's checkpoint as the backtracking endpoint, and the alternating update operation continues.

[0087] The present invention also provides a storage medium on which a computer program is stored, which, when executed by a processor, implements a method for synchronizing local blockchain ledger data.

[0088] 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 executes the program to implement a method for synchronizing local blockchain ledger data.

[0089] To minimize redundant calculations during inventory checks, this invention introduces the concept of checkpoints. At the end of each inventory check, the checked positions are saved, thus resolving some of the redundant calculations. However, in blockchain fork scenarios, checkpoints may be marked on invalid forks, rendering them invalid. Therefore, two checkpoints are introduced. During traceability inventory checks, whenever either checkpoint is encountered, the value of the other checkpoint is updated. The two checkpoints alternately move upwards on the chain with each inventory check. This significantly reduces the computational burden of redundant verification, even if a checkpoint is marked on an invalid fork.

[0090] The above description, in conjunction with specific preferred embodiments, provides a further detailed explanation of the present invention. It should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various simple deductions or substitutions can be made without departing from the concept of the present invention, and all such modifications and substitutions should be considered within the scope of protection of the present invention.

Claims

1. A method for synchronizing local ledger data in a blockchain, characterized in that, Includes the following steps: S1. When the blockchain is being inventoried, each time an inventory is completed, the positions of the inventoried blocks are saved, and the two inventoried block positions are marked as two checkpoints. The hash values ​​of the two corresponding blocks are written to the two checkpoints respectively. S2. Start the backtracking inventory of the new block. When backtracking to one of the checkpoints, update the other checkpoint with the new block location marker and remove the original block location marker corresponding to the other checkpoint. S3. As the height of the blockchain increases and multiple inventory checks are performed, the two checkpoints are updated alternately on the blockchain and move along the direction of the blockchain's height increase. S4. If no fork occurs in the blockchain extension, the two checkpoints perform the alternating update operation of step S3; 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 fork chain, the two checkpoints perform the alternating update operation of step S3. S6. 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 invalid fork chain, the new checkpoint is generated with the checkpoint of the main chain as the backtracking endpoint, and the alternating update operation of step S3 continues to be executed.

2. The blockchain local ledger data synchronization method according to claim 1, characterized in that, Step S1 further includes: When the blockchain performs its first block count, the blocks counted are 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 to the first checkpoint. The position of the first block count is used as the second checkpoint, and the hash value of the first block count is written to the second checkpoint.

3. The blockchain local ledger data synchronization method according to claim 2, characterized in that, Step S2 includes: S21. When starting the next block count, start counting from block n. When backtracking to block n-1, if the hash value of block n-1 is found to be consistent with the hash value of the second checkpoint, then the backtracking of block n stops, the hash value of block n is written to the first checkpoint, the mark of the first checkpoint is updated to the position of block n, and the block count ends. S22. When starting the next block count, begin counting from block (n+1). When backtracking to block (n), if the hash value of block (n) matches the hash value of the first checkpoint, the backtracking of block (n+1) stops, the hash value of block (n+1) is written to the second checkpoint, the mark of the second checkpoint is updated to the position of block (n+1), and the block count ends; n is an integer and n≥2; Step S3 includes: During the lengthening of the blockchain and multiple inventory checks, steps S21 and S22 are executed alternately to update the position and hash value of the first and second checkpoints in turn, and to move forward alternately on the chain until pointing to the latest inventory block.

4. The blockchain local ledger data synchronization method according to claim 1, characterized in that, The specific execution steps of step S3 include: S31. Inventory begins. Locate the latest block and obtain its hash value. Use this hash value to perform a search on the local node. If a specific block is found, it means the block on this node is valid, and the search is successful. If a specific block cannot be found on the local node based on this hash value, it means the local node is missing the block, and the search fails. S32. If the retrieval fails, download the block again; S33. If the retrieval is successful, calculate the hash value of this block and compare this hash value 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 of the marker variables in the first checkpoint and the second checkpoint, it means that one of the checkpoints that has been inventoried has been encountered. Then, use the hash value of the block at the beginning of this inventory to update the marker variable of the other checkpoint, and then return and end this inventory. S34. If the retrieval is successful and the hash value of this block is different from the values ​​in the first checkpoint and the second checkpoint, then the previous inventory block is found through the information in the block header, and steps S31 to S34 are executed in a loop.

5. The blockchain local ledger data synchronization method according to claim 1, characterized in that, Step S4 specifically includes: S4. If no fork occurs in the blockchain extension, backtracking is performed from the latest block along the blockchain until the previous checkpoint on the blockchain is reached. The latest block is then updated as the new checkpoint, which together with the previous checkpoint on the blockchain constitutes two new checkpoints.

6. The blockchain local ledger data synchronization method according to claim 1, characterized in that, Step S5 specifically includes: When a fork occurs during the extension of a blockchain, and one checkpoint is on the main chain while the other checkpoint is on the valid fork chain, the latest block starts backtracking from the valid fork chain and stops when it reaches the previous checkpoint on the valid fork chain. The latest block is then updated as a new checkpoint, and this new checkpoint, together with the previous checkpoint on the valid fork chain, constitutes two new checkpoints.

7. The blockchain local ledger data synchronization method according to claim 1, characterized in that, Step S6 specifically includes: When a fork occurs during the extension of the blockchain, and one checkpoint is located on the main chain while another checkpoint is located on an invalid fork chain, the latest block starts backtracking from the valid fork chain and stops when it reaches the checkpoint on the main chain. This latest block is then updated as the new checkpoint, and this new checkpoint, together with the checkpoint on the main chain, constitutes two new checkpoints.

8. A blockchain local ledger data synchronization system, characterized in that, This includes the blockchain and multiple block nodes set up on the blockchain, and executes: When the blockchain is conducting a block inventory, each time an inventory is completed, the positions of the inventoried blocks are saved, and the two inventoried block positions are marked as two checkpoints. The hash values ​​of the two corresponding blocks are written to the two checkpoints respectively. Initiate a backtracking inventory of the new block. When backtracking to one of the checkpoints, update the other checkpoint with the new block location marker and remove the original block location marker corresponding to the other checkpoint. As the blockchain lengthens and multiple inventory checks occur, the two checkpoints are updated alternately on the blockchain and move along the length of the blockchain. When no fork occurs in the blockchain extension, the two checkpoints perform alternating update operations. When a blockchain extension has a fork, and one checkpoint is located on the main chain while the other checkpoint is located on the valid fork chain, the two checkpoints perform alternating update operations. When a blockchain extension has a fork, and one checkpoint is located on the main chain while the other checkpoint is located on an invalid fork chain, a new checkpoint is generated with the main chain's checkpoint as the backtracking endpoint, 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 the processor, it implements the blockchain local ledger data synchronization method as described in any one of claims 1 to 7.

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

Images