Historical account book data correctness verification method and device, equipment and storage medium

Abstract

The application belongs to the technical field of blockchains, solves the problem of untrustworthy blockchain data caused by malicious tampering of historical block data stored by a blockchain node in the prior art, and provides a historical ledger data correctness verification method, device, equipment and storage medium. The method comprises the following steps: an accounting node acquires first block data corresponding to a first verification block in a blockchain ledger and locally stored first source data, generates first verification data by using the first source data based on an index parameter type contained in the first block data, and performs accounting node ledger correctness verification by comparing each index parameter of the first block data and the first verification data; correctness verification of historical blocks can be performed regularly or irregularly, so that private tampering of the first source data or the first block data by the accounting node can be avoided.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a method, apparatus, device, and storage medium for verifying the correctness of historical ledger data. Background Technology

[0002] Blockchain technology is built on a transmission network (also known as a blockchain network). Distributed node devices (hereinafter referred to as nodes) in the transmission network run blockchain programs to generate block data according to a preset consensus strategy, and use a chain data structure to verify and store block data, ultimately realizing a data anti-tampering mechanism and providing a new, secure, and reliable technical approach for business operations.

[0003] In existing technologies, data to be stored on a blockchain must be agreed upon through blockchain consensus before it can be stored. Since the latest data stored on the blockchain has been agreed upon through blockchain consensus, all nodes with accounting permissions on the blockchain record this data, ensuring that the data can be rolled back to its original state when used later. However, administrators of each accounting node can modify the data stored on the nodes they manage; that is, historical block data stored on the blockchain can be modified by their administrators. If the historical block data of a node is maliciously tampered with, then the data will inevitably be untrustworthy when used later. Therefore, it is necessary to implement an effective tamper-proof monitoring mechanism for historical block data stored on the blockchain to improve the trustworthiness of blockchain data. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide a method, apparatus, device and storage medium for verifying the correctness of historical ledger data, in order to solve the problem of untrustworthy blockchain data caused by malicious tampering of historical block data stored by blockchain nodes in the prior art.

[0005] The technical solution adopted in this invention is:

[0006] On one hand, the present invention provides a method for verifying the correctness of historical ledger data, applied to each accounting node of blockchain archived data, the method comprising:

[0007] Obtain the first block data and the first source data corresponding to the first verification block, wherein the first block data is the block data of the first verification block in the blockchain ledger maintained by the ledger node, and the first source data is the storage data corresponding to the first block data stored locally by the ledger node.

[0008] Based on the various indicator parameters of the first block data, first verification data is generated using the first source data, wherein the first verification data includes all categories of the indicator parameters of the first block data;

[0009] A first type of verification is performed by comparing the various indicator parameters of the first verification data and the first block data, and a verification report is generated.

[0010] The first type of verification is the verification of the correctness of the ledger at the accounting node.

[0011] Preferably, the verification report includes verification logs and abnormal block data.

[0012] Preferably, the verification of all historical blocks of the ledger node is completed by multiple verification cycles, and each verification cycle includes one or more target blocks.

[0013] Preferably, the block heights of the target blocks within the verification period are continuous.

[0014] Preferably, all unverified historical blocks are reordered by block height to obtain a first block order, and each target block within the verification period is a consecutive block in the first block order.

[0015] Preferably, the method further includes:

[0016] Obtain the total number of blocks corresponding to the target block that needs to be verified in the current verification period and the verification report of the first verification block corresponding to the target block being verified.

[0017] According to the verification report, the verification label of the first verification block is adjusted to the second label;

[0018] If the first verification block is not the last block to be verified in the current verification cycle, repeat the above operation; otherwise, end the block verification for the current verification cycle.

[0019] Preferably, determining each of the target blocks in any verification period includes:

[0020] Obtain the first height corresponding to each of the remaining unverified basic blocks in this round of blockchain verification and the second height consisting of all the target blocks in the current verification period;

[0021] Based on the first height and the second height, consecutive base blocks are randomly selected from each base block as each target block;

[0022] The smallest block height in each target block is: 0 < h ≤ (HK), where H, h, and K are all positive integers, H is the first height, and K is the second height.

[0023] On the other hand, the present invention also provides a historical ledger data correctness verification device, applied to each ledger node of blockchain archived data, including:

[0024] Data acquisition module: used to acquire the first block data and the first source data corresponding to the first verification block, wherein the first block data is the block data of the first verification block in the blockchain ledger maintained by the accounting node, and the first source data is the storage data corresponding to the first block data stored locally by the accounting node.

[0025] Data generation module: used to generate first verification data using the first source data based on the various indicator parameters of the first block data, wherein the first verification data includes all categories of the indicator parameters of the first block data;

[0026] Data verification module: used to compare the various indicator parameters of the first verification data and the first block data to perform a first type of verification and generate a verification report;

[0027] The first type of verification is the verification of the correctness of the ledger at the accounting node.

[0028] On the other hand, the present invention also provides an electronic device, comprising: at least one processor, at least one memory, and computer program instructions stored in the memory, which, when executed by the processor, implement the method described in any of the preceding claims.

[0029] On the other hand, the present invention also provides a medium having computer program instructions stored thereon, which, when executed by a processor, implement the method described in any of the preceding claims.

[0030] In summary, the beneficial effects of the present invention are as follows:

[0031] The present invention provides a method, apparatus, device, and storage medium for verifying the correctness of historical ledger data. Based on the first verification block to be verified, the ledger node obtains the first block data corresponding to the first verification block in the blockchain ledger, and simultaneously obtains the first source data corresponding to the first verification block stored locally by the ledger node. Based on the indicator parameter types contained in the first block data, first verification data is generated using the first source data. The indicator parameter types of the first verification data are consistent with those of the first block data. Then, the indicator parameters of the first block data and the first verification data are compared. If they are consistent, the verification passes; if they are inconsistent, the first block data or the first source data has been tampered with. By periodically or irregularly verifying the correctness of historical blocks, the unauthorized tampering of the first source data or the first block data by the ledger node can be prevented. Furthermore, ensuring the consistency between the first source data and the first block data guarantees the effectiveness of the blockchain's verification of data consistency for all ledger nodes regarding the first verification block. Attached Figure Description

[0032] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the embodiments of the present invention will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort, and these are all within the protection scope of the present invention.

[0033] Figure 1 This is a flowchart illustrating the method for verifying the correctness of historical ledger data in Embodiment 1 of the present invention.

[0034] Figure 2 This is a schematic diagram of the process for obtaining block data and source data in Embodiment 1 of the present invention;

[0035] Figure 3 This is a schematic diagram of the process for obtaining the first verification result in Embodiment 1 of the present invention;

[0036] Figure 4 This is a schematic diagram of the process for obtaining the second verification result in Embodiment 1 of the present invention;

[0037] Figure 5 This is a schematic diagram of the blockchain transaction device structure in Embodiment 2 of the present invention;

[0038] Figure 6 This is a schematic diagram of the electronic device in Embodiment 3 of the present invention. Detailed Implementation

[0039] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. In the description of the present invention, it should be understood that the terms "center," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicate orientations or positional relationships based on the orientations or positional relationships shown in the accompanying drawings, and are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the referred device or element must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the present invention. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element. Where there is no conflict, the various features of this invention and its embodiments can be combined with each other, all of which are within the scope of protection of this invention.

[0040] Blockchain technology is built on a transmission network (also known as a blockchain network). Distributed node devices in the transmission network (hereinafter referred to as nodes or member nodes) run blockchain programs to generate, verify, and store block data on the chain, ultimately realizing a data anti-tampering mechanism and providing a new, secure, and reliable technical approach for business operations.

[0041] In a blockchain network, each node can be a server or a terminal device. A server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. Terminal devices can be smartphones, tablets, laptops, desktop computers, smart speakers, smartwatches, etc., but are not limited to these. Nodes can be directly or indirectly connected via wired or wireless communication, and this application does not impose any restrictions on this.

[0042] Example 1

[0043] Please see Figure 1 , Figure 1 The historical ledger data correctness verification method in Embodiment 1 of this invention is applied to any accounting node and / or verification node in a blockchain. Each time a new block is generated in the blockchain, each accounting node synchronizes the new block to its maintained ledger. Each accounting node has management permissions corresponding to the ledger it maintains; that is, each accounting node can modify the ledger data it maintains and the stored source data without the permission of other nodes. Each accounting node does not have the permission to manage the ledgers maintained by other nodes; that is, accounting node A cannot access or modify the ledger maintained by accounting node B. To prevent accounting nodes in the blockchain from tampering with the historical block data in their maintained ledgers, the method provided by this invention includes:

[0044] S1: In response to the data verification request for historical block verification, obtain the first block data and first source data corresponding to the first verification block of each ledger node, wherein the first source data is the storage data corresponding to the first block data stored locally by the ledger node;

[0045] Specifically, to prevent the tampering of historical block data and / or the source data corresponding to block data in the blockchain, this invention periodically or irregularly verifies the block data and corresponding source data of the ledger maintained by each accounting node in the blockchain. This includes verifying the correctness of the block data of the accounting node and the source data corresponding to the block data stored locally, as well as verifying the consistency of the block data corresponding to the same block height in the ledgers of all accounting nodes on the blockchain. The correctness verification involves checking whether the source data stored locally by the accounting node matches the block data recorded by the accounting node in the blockchain ledger. The correctness verification can be a self-checking program initiated by the accounting node or a verification program initiated by the verification node and executed by the accounting node. It should be noted that the block data generated by different accounting nodes in the blockchain for the same block height is consistent. The data verification request retrieves the first block data of the block to be verified on each ledger node, and each ledger node retrieves the corresponding first source data based on its first block data. It should be noted that any member node of the blockchain that meets the data verification permission can retrieve the first block data of each ledger node according to its permission. Due to access permission issues, only each ledger node can retrieve its own first source data corresponding to the first block data.

[0046] S2: Perform a first type of verification based on the first block data and the corresponding first source data in the blockchain ledger maintained by the ledger node to obtain a first verification result. The first type of verification is the ledger correctness verification of the ledger node, that is, whether the first block data is generated from the first source data.

[0047] Specifically, since other nodes cannot access the first source data stored by the ledger node, the verification of the first source data corresponding to the first block data can only be completed by the ledger node itself. Each ledger node retrieves the corresponding first source data and performs the first type of verification based on the block information (block height) of the block to be verified as specified in the data verification request (verification program initiated by the verification node or automatically triggered by the ledger node). If the first block data matches the first source data, it means that the ledger node's blockchain ledger data for the first source data is correct.

[0048] S3: Perform a second type of verification based on the data of each first block to obtain a second verification result. The second type of verification is a network-wide consistency verification of the ledger, and the block height of each first block data is the same.

[0049] Specifically, in the ledgers maintained by each accounting node on the blockchain, the block data (usually the hash value of the data) recorded at the same block height should be consistent. If one or more first block data are inconsistent with the first block data of other accounting nodes, it is considered that there is a problem of the ledger of the accounting node being tampered with. Therefore, the network-wide consistency check will fail and abnormal block information will be given, including block height, accounting node information, etc.

[0050] S4: Output a verification report based on the first verification result and / or the second verification result.

[0051] Specifically, if the node performing data verification is an accounting node, it can perform the first type of verification of its own node and the second type of verification for network-wide consistency. Based on the results of the first and second verifications, a verification report is output. If only one type of verification, the first or the second, is performed, a verification report is output based on that verification. If the node performing data verification is a non-accounting node, it can only complete the second type of verification, and a verification report is output based on the results of the second type of verification.

[0052] In one embodiment, when verifying the correctness of blockchain ledger data maintained by each accounting node against locally stored data, the method includes:

[0053] Obtain the first block data and the first source data corresponding to the first verification block, wherein the first block data is the block data of the first verification block in the blockchain ledger maintained by the ledger node, and the first source data is the storage data corresponding to the first block data stored locally by the ledger node.

[0054] Based on the various indicator parameters of the first block data, first verification data is generated using the first source data, wherein the first verification data includes all categories of the indicator parameters of the first block data;

[0055] A first type of verification is performed by comparing the various indicator parameters of the first verification data and the first block data, and a verification report is generated.

[0056] The first type of verification is the verification of the correctness of the ledger at the accounting node.

[0057] Specifically, based on the block height that needs to be verified, the ledger node obtains the first block data and the first source data corresponding to that block height. Then, it generates the first verification data from the first source data. If the ledger node does not have blockchain ledger data and the source data stored locally has not been tampered with, the first verification data and the first block data should be completely consistent. That is, the types of indicator parameters contained in the first verification data and the first block data are consistent, and the data of each indicator parameter is also consistent. Then, a verification report is generated based on the comparison results.

[0058] In one embodiment, when a verification node performs a network-wide consistency verification of historical blocks in the blockchain ledger, the method includes:

[0059] In response to the data verification request for historical block verification, the first block data corresponding to the first verification block of each ledger node is obtained, wherein the block height of each first block data is the same;

[0060] A second type of verification is performed by comparing the various indicator parameters of each first block of data, and a verification report is generated.

[0061] The second type of verification is the network-wide consistency verification of the first block data.

[0062] Specifically, based on the data verification request, the verification node obtains the data of each first block corresponding to the first verification block in the blockchain ledger maintained by each accounting node, and then compares the various indicator parameters of each first block data. If the data of each first block is consistent, it is considered that the first verification block has not been tampered with in the blockchain ledger of each accounting node. If they are inconsistent, it is considered that one or more blockchain ledgers have tampered with the block data of the first verification block. Then, a verification report is generated based on the comparison results.

[0063] In one embodiment, the verification report includes verification logs and abnormal block data.

[0064] Specifically, the verification log includes: verification time, verification method, block height, and information on participating accounting nodes. Verification methods include random sampling, continuous sampling, active verification, and automatic verification. If there is no tampered block data, the abnormal block data is empty. If there is tampered block data, the abnormal block data includes: accounting node information, abnormal block data type, and abnormal data. The abnormal block data type includes the first block data and the first source data.

[0065] In one embodiment, the method further includes:

[0066] S5: Obtain the total number of verification blocks corresponding to the target block that needs to be verified in the current verification period and the verification report corresponding to the first verification block;

[0067] S6: Based on the verification report of the current verification block, adjust the verification label of the first verification block to the second label;

[0068] S7: If the first verification block is not the last block to be verified in the current verification cycle, repeat the above operation; otherwise, end the block verification for the current verification cycle.

[0069] Specifically, for each completed transaction on the blockchain, the ledger maintained by each accounting node adds a block, i.e., the block height of the blockchain increases by 1. Transactions on the blockchain can occur continuously or intermittently; therefore, the block height is constantly updated as transactions proceed, and historical blocks are continuously generated. Periodic anti-tampering checks on historical block data are necessary to prevent accounting nodes from unauthorized modification of their ledger data. As the number of blocks on the blockchain increases, the number of blocks to be checked in each verification cycle can be fixed or can vary depending on the number of blocks currently awaiting verification. In one embodiment, let the current verification cycle... The number of blocks to be verified in a given period is the preset number of verification blocks. For ease of description, the first verification block is the most recently verified block. After the first verification block completes the first type of verification and / or the second type of verification, a corresponding verification report is generated. Then, the verification label of the first verification block is changed from the first label corresponding to unverified blocks to the second label corresponding to verified blocks. The first label is used to identify unverified blocks in the target blocks to be verified in the current verification period, and the second label is used to identify verified blocks in the target blocks to be verified in the current verification period. The second label includes a first sub-label for identifying abnormal blocks and a second sub-label for identifying normal blocks. Then, it is determined whether the first verification block is the last block to be verified in the current verification period. If so, the current period verification ends; otherwise, the above verification process is repeated to perform the first type of verification and / or the second type of verification on the new first verification block.

[0070] In one embodiment, if it is determined that the first verification block is not the last block to be verified in the current verification cycle, it is necessary to further determine whether the verification time of the current verification cycle has expired. If it has expired, the current verification cycle ends, and each unverified target block is included in the unverified blocks to be verified in this round of verification, and the unverified blocks are verified by subsequent verification cycles. If the expiration time of the current verification cycle has not yet arrived, the new target blocks are verified.

[0071] In one embodiment, based on the number of second tags (denoted as the number of first tags) and the number of target blocks (denoted as the first number), it is determined whether the first verification block is the last target block. Specifically, the number of tags corresponding to the second tags in the current verification period is counted, and the number of tags of the second tags is compared with the number of blocks of the target blocks. If the number of tags of the second tags is less than the number of blocks of the target blocks, the anti-tampering detection of the target blocks continues to be performed until the number of first tags is equal to the first number, and the current verification period ends.

[0072] In one embodiment, please refer to Figure 2 S1 includes:

[0073] S11: Obtain the verification frequency and verification data for the current verification period;

[0074] S12: Determine the initiation time of the data verification request based on the verification frequency;

[0075] S13: Determine the block information of the first verification block of the data verification request based on the verification data;

[0076] S14: Based on the initiation time and the block information of the first verification block, obtain each first block data and the first source data;

[0077] The verification data includes the first number of blocks to be verified in the current verification period, the second number of verified blocks, the third number of unverified blocks, and the first verification block for this verification.

[0078] Specifically, a round of testing is defined as completing an anti-tampering check on all historical block data. A round of testing includes at least one verification cycle. The verification frequency of each verification cycle can be set according to the type of transaction to be completed by the blockchain. Taking the consortium blockchain corresponding to wealth management subsidiaries (wealth management subsidiaries) and sales agents as an example, the transactions between wealth management subsidiaries and sales agents are usually completed in specific time periods and are intermittent. Therefore, the current verification cycle can be set in multiple intermittent time periods of the transaction, and the verification frequency can be set according to the intermittent time. For example, the stock and bond markets usually have specific trading hours, so a trading day or a market closure day can be used as a verification cycle. Corresponding verification frequencies are set for different verification cycles. Data verification requests are initiated based on the verification frequency, and the block information of the first verification block is determined according to the verification data. The verification data includes the total number of blocks to be verified in the current verification cycle, the number of blocks that have been verified, the number of unverified blocks, and the first verification block determined according to the verification rules. The verification rules include random selection from unverified blocks and sequential selection according to block height order.

[0079] In one embodiment, S11 includes:

[0080] S111: Obtain the total number of remaining unverified blocks in this round of verification and the maximum number of blocks that can be verified in the current verification cycle;

[0081] S112: Based on the total number of remaining blocks and the maximum number of blocks, generate the verification frequency for the current verification period and the first number of target blocks that need to be verified.

[0082] Specifically, when verifying historical blocks at the start of the current verification cycle, it is necessary to determine the number of blocks to be verified and the verification frequency for the current verification cycle. Let the number of blocks to be verified in the current verification cycle be the first quantity, and record each block to be verified in the current verification cycle as the target block. The first quantity is determined by the total number of remaining unverified blocks in the blockchain and the maximum number of blocks corresponding to the highest verification frequency in the current verification cycle. The total number of remaining blocks is equal to the latest block height (number of blocks) of the blockchain minus the height (number of blocks) of the blocks that have been verified. It should be noted that if there is an unverified block, the height of the unverified block is increased by 1; similarly, if there is a verified block... If a block is checked, its height is incremented by 1. Therefore, the height of each checked or unchecked block is not the same as its actual height in the ledger. For example, if block A is a checked block with a height of 1000 in the ledger, and block B is an unchecked block with a height of 1500 in the ledger, in this round of checks, the checked blocks include 500 blocks (including block A) with heights less than 1000 and 300 blocks with heights between 1001 and 1500. Therefore, the height of block A in the checked blocks is 500, and the height of block B in the unchecked blocks is 700. Furthermore, after determining the first number of blocks to be checked in the current check cycle, the check frequency is determined based on this first number. Furthermore, taking the current verification period as 1 hour, the maximum number of blocks that can be verified is 1000. At this time, the latest block height of the blockchain is 5050, and the number of blocks completed after the end of the previous verification period is 4250. Therefore, the first block number of the current verification period is 800, and the verification frequency is 4.5 seconds / time. If the number of blocks completed after the end of the previous verification period is 4000, then the first block number of the current verification period is 1000, and the verification frequency is 3.6 seconds / time.

[0083] It should be noted that when performing anti-tampering verification on historical blocks in the ledger of each accounting node on the blockchain, completing one round of anti-tampering verification on all historical blocks is recorded as one round of verification. After completing this round of verification, the next round of verification will begin in the next verification cycle. The first verification cycle will be the first verification cycle of the next round of verification. Since the blocks on the blockchain are constantly updated as transactions proceed, separating the first and last verification cycles of two adjacent rounds of verification helps to simplify verification data, improve verification efficiency, and prevent missed detections.

[0084] In one embodiment, the first number of target blocks are consecutive blocks, and obtaining the first number of target blocks corresponding to the current verification period includes:

[0085] Obtain the remaining unverified basic blocks in this round of blockchain verification and the first quantity;

[0086] Based on the first quantity, each of the basic blocks is divided into multiple sampling segments according to the continuous block height, and the number of the basic blocks corresponding to each sampling segment is the first quantity;

[0087] All the base blocks of a sampling segment are randomly selected as the target blocks.

[0088] Specifically, the block heights of the target blocks to be verified in the current verification cycle are continuous. For example, if the number of blocks to be verified in the current verification cycle is 100, then the block heights of the 100 historical blocks are N, N+1, N+2, ..., N+97, N+98, where N is a positive integer greater than or equal to 1. This should be understood as the block heights of the target blocks in the ledger being continuous, or the target blocks being in the unverified block cluster, where all unverified historical blocks are rearranged according to their block heights. The first block is formed by sequentially corresponding to the blocks in the first block sequence. Each target block is a consecutive block in the first block sequence. For example, the target blocks selected in the first verification cycle are 100 blocks with a block height of 100-1099; the target blocks selected in the second verification cycle are 100 blocks with a block height of 1200-2199; then the consecutive blocks selected in the third verification cycle can be 1000 target blocks composed of 1-99, 1100-1199, and 2200-3001.

[0089] Furthermore, in order to facilitate the rapid determination of the first number of target blocks, the unverified basic blocks in this round of verification are divided into multiple sampling segments according to the first number, and all basic blocks of a random sampling segment are selected as the target blocks of the current verification period. By pre-dividing all basic blocks into multiple continuous sampling segments and then directly randomly selecting sampling segments, it is ensured that the block height of each target block verified each time is continuous.

[0090] In one embodiment, the first number of target blocks are consecutive blocks, and obtaining the first number of target blocks corresponding to the current verification period includes:

[0091] Obtain the first height corresponding to each of the remaining unverified basic blocks in this round of blockchain verification and the second height corresponding to the first quantity;

[0092] Based on the first height and the second height, consecutive target blocks are randomly selected from each of the base blocks;

[0093] The smallest block height in each target block is: 0 < h ≤ (HK), where H, h, and K are all positive integers, H is the first height, and K is the second height.

[0094] Specifically, the block heights of the target blocks to be verified in each verification cycle are continuous. The first height represents the number of blocks corresponding to all unverified basic blocks, and the second height represents the number of blocks corresponding to all target blocks to be verified in the current verification cycle. For example, if the number of unverified basic blocks is 5050, then the first height is 5050. If the number of target blocks to be verified in the current verification cycle is 1000, then the second height is 1000. Based on the first and second heights, each continuous basic block corresponding to the second height is randomly selected as a target block. The smallest block height of the target block is 0 < h ≤ (HK), where H, h, and K are all positive integers, H is the first height, and K is the second height, thus ensuring that K target blocks can be successfully selected.

[0095] In one embodiment, please refer to Figure 3 S2 includes:

[0096] S21: Retrieve the first source data stored in the ledger node based on the first block data of the ledger node;

[0097] S22: Based on the various indicator parameters of the first block data, generate various verification parameters corresponding to the various indicator parameters using the first source data;

[0098] S23: Compare each of the stated index parameters with the corresponding verification parameters, and generate the first verification result based on the comparison result.

[0099] In one embodiment, the indicator parameters include ProposalHash, BlockHash, BlockDataHash, and CommitHash.

[0100] Specifically, each ledger node needs to verify the correctness of its first block data and first source data, determine the various indicator parameters representing the first source data in the first block data, generate various verification parameters corresponding to the indicator parameters using the first source data, and compare each indicator parameter with each verification parameter one by one. If they match, the verification passes; otherwise, the first source data and / or the first block data has been tampered with. The indicator parameters include ProposalHash, BlockHash, BlockDataHash, and CommitHash. ProposalHash is the hash value generated based on the Proposal (a type of endorsement request for nodes in the channel) data of the first source data. BlockHash is the unique identifier of the block corresponding to the first source data, called the block hash, which is a digital fingerprint calculated from the transaction records and metadata of the block. BlockDataHash is the hash of all transactions contained in the block corresponding to the first source data, that is, the hash of the block data. CommitHash is the commit time hash of the block corresponding to the first source data.

[0101] It should be noted that: for data correctness verification, each accounting node can proactively perform verification, or the verification node can issue a verification request, and the accounting node can perform the verification based on the verification request.

[0102] In one embodiment, please refer to Figure 4 S3 includes:

[0103] S31: Obtain the various indicator parameters of each first block of data;

[0104] S32: Compare the various indicator parameters of each first block of data to perform a consistency check, and obtain the second check result.

[0105] Specifically, during the network-wide ledger consistency verification, the verification node obtains the first block data at the same block height from each accounting node, and then compares the various indicator parameters of each first block data one by one, specifically comparing the ProposalHash, BlockHash, BlockDataHash, and CommitHash of each first block data. If there is an inconsistency, it means that at least one of the first block data participating in the comparison has been tampered with. If all the indicator parameters of all first block data are consistent, it means that the network-wide ledger consistency verification has passed, and a second verification result is generated based on the comparison result.

[0106] The historical ledger data correctness verification method of the present invention involves the following steps: Based on the first verification block to be verified, the ledger node obtains the first block data corresponding to the first verification block in the blockchain ledger, and simultaneously obtains the first source data corresponding to the first verification block stored locally by the ledger node. Based on the indicator parameter types contained in the first block data, first verification data is generated using the first source data. The indicator parameter types of the first verification data are consistent with those of the first block data. Then, the indicator parameters of the first block data and the first verification data are compared. If they are consistent, the verification passes; if they are inconsistent, the first block data or the first source data has been tampered with. By periodically or irregularly verifying the correctness of historical blocks, the method can prevent ledger nodes from privately tampering with the first source data or the first block data. Furthermore, ensuring the consistency between the first source data and the first block data guarantees the effectiveness of the blockchain's verification of data consistency for all ledger nodes regarding the first verification block.

[0107] The historical ledger data correctness verification method of the present invention involves completing the first sub-task of blockchain consensus for each target transaction within a partition network when the blockchain partition network submits a transaction. The target file that has completed the first sub-task is then sent to the Master node to execute the second sub-task of blockchain consensus. This enables the Master node to improve the consensus task of each target transaction submitted by each partition network at high concurrency. At the same time, since each partition network has completed the first sub-task, each target transaction corresponding to the target block belongs to only one partition network. The first partition network needs to synchronize the target block to its partition ledger, while other partition networks do not need to synchronize the target block, thereby improving the accounting efficiency of the partition network.

[0108] Example 2

[0109] Please see Figure 5 The present invention, based on the historical ledger data correctness verification method of Embodiment 1, also provides a historical ledger data correctness verification device, applied to each accounting node of blockchain archived data, including:

[0110] Data acquisition module: used to acquire the first block data and the first source data corresponding to the first verification block, wherein the first block data is the block data of the first verification block in the blockchain ledger maintained by the accounting node, and the first source data is the storage data corresponding to the first block data stored locally by the accounting node.

[0111] Data generation module: used to generate first verification data using the first source data based on the various indicator parameters of the first block data, wherein the first verification data includes all categories of the indicator parameters of the first block data;

[0112] Data verification module: used to compare the various indicator parameters of the first verification data and the first block data to perform a first type of verification and generate a verification report;

[0113] The first type of verification is the verification of the correctness of the ledger at the accounting node.

[0114] In one embodiment, the verification report includes verification logs and abnormal block data.

[0115] In one embodiment, the verification of all historical blocks of the ledger node is completed by multiple verification cycles, each verification cycle including one or more target blocks.

[0116] Preferably, the block heights of the target blocks within the verification period are continuous.

[0117] In one embodiment, all unverified historical blocks are reordered by block height to obtain a first block order, and each target block within the verification period is a consecutive block in the first block order.

[0118] In one embodiment, the device further includes:

[0119] Verification information acquisition module: used to acquire the total number of blocks corresponding to the target block that needs to be verified in the current verification period and the verification report of the first verification block corresponding to the target block being verified in the current verification period;

[0120] Verification label change module: used to adjust the verification label of the first verification block to the second label according to the verification report;

[0121] The block verification module is used to repeat the above operation if the first verification block is not the last block to be verified in the current verification cycle; otherwise, the block verification of the current verification cycle is terminated.

[0122] In one embodiment, determining each of the target blocks for any verification period includes:

[0123] Height acquisition unit: acquires the first height corresponding to each of the remaining unverified basic blocks in this round of verification and the second height corresponding to the first quantity;

[0124] Block selection unit: Based on the first height and the second height, randomly select consecutive target blocks from each of the basic blocks;

[0125] The smallest block height in each target block is: 0 < h ≤ (HK), where H, h, and K are all positive integers, H is the first height, and K is the second height.

[0126] This invention provides a historical ledger data correctness verification device. Based on the first verification block to be verified, the ledger node obtains the first block data corresponding to the first verification block in the blockchain ledger, and simultaneously obtains the first source data corresponding to the first verification block stored locally by the ledger node. Based on the indicator parameter types contained in the first block data, first verification data is generated using the first source data. The indicator parameter types of the first verification data are consistent with those of the first block data. Then, the indicator parameters of the first block data and the first verification data are compared. If they are consistent, the verification passes; if they are inconsistent, the first block data or the first source data has been tampered with. By periodically or irregularly verifying the correctness of historical blocks, the device can prevent ledger nodes from privately tampering with the first source data or the first block data. Furthermore, ensuring the consistency between the first source data and the first block data guarantees the effectiveness of the blockchain's data consistency verification for all ledger nodes regarding the first verification block.

[0127] Example 3

[0128] This invention provides an electronic device and a storage medium; please refer to [link / reference]. Figure 6 It includes at least one processor, at least one memory, and computer program instructions stored in the memory.

[0129] Specifically, the processor may include a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of the present invention. The electronic device includes at least one of the following: a computer, a mobile terminal, a PC, a tablet computer, etc.

[0130] The memory may include a large-capacity storage device for data or instructions. For example, and not limitingly, the memory may include a hard disk drive (HDD), a floppy disk drive, flash memory, an optical disk drive, a magneto-optical disk drive, magnetic tape, or a Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, the memory may include removable or non-removable (or fixed) media. Where appropriate, the memory may be internal or external to a data processing device. In a particular embodiment, the memory is a non-volatile solid-state memory. In a particular embodiment, the memory includes a read-only memory (ROM). Where appropriate, the ROM may be a mask-programmed ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), an electrically rewritable ROM (EAROM), or flash memory, or a combination of two or more of these.

[0131] The processor implements any of the historical ledger data correctness verification methods in the above embodiments by reading and executing computer program instructions stored in the memory.

[0132] In one example, the electronic device may also include a communication interface and a bus. The processor, memory, and communication interface are connected via the bus and communicate with each other.

[0133] The communication interface is mainly used to enable communication between various modules, devices, units and / or equipment in the embodiments of the present invention.

[0134] A bus, including hardware, software, or both, couples components of an electronic device together. For example, and not limitingly, a bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, a bus may include one or more buses. While specific buses are described and illustrated in embodiments of the invention, the invention contemplates any suitable bus or interconnect.

[0135] It should be clarified that the present invention is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present invention is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of the present invention.

[0136] The functional blocks shown in the above-described structural diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this invention are programs or code segments used to perform the required tasks. The programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried in a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0137] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for verifying the correctness of historical ledger data, characterized in that, The method, applied to each ledger node storing blockchain archived data, includes: Obtain the first block data and the first source data corresponding to the first verification block, wherein the first block data is the block data of the first verification block in the blockchain ledger maintained by the ledger node, and the first source data is the storage data corresponding to the first block data stored locally by the ledger node; all historical block verifications of the ledger node are completed by multiple verification cycles, and each verification cycle includes one or more target blocks; Based on the various indicator parameters of the first block data, first verification data is generated using the first source data, wherein the first verification data includes all categories of the indicator parameters of the first block data; A first type of verification is performed by comparing the various indicator parameters of the first verification data and the first block data, and a verification report is generated. The first type of verification is the verification of the correctness of the ledger at the accounting node.

2. The method for verifying the correctness of historical ledger data according to claim 1, characterized in that, The verification report includes verification logs and abnormal block data.

3. The method for verifying the correctness of historical ledger data according to claim 1, characterized in that, The block heights of each target block within the verification period are continuous.

4. The method for verifying the correctness of historical ledger data according to claim 1 or 3, characterized in that, All unverified historical blocks are reordered by block height to obtain a first block order, and each target block within the verification period is a consecutive block in the first block order.

5. The method for verifying the correctness of historical ledger data according to claim 1, characterized in that, The method further includes: Obtain the total number of blocks corresponding to the target block that needs to be verified in the current verification period and the verification report of the first verification block corresponding to the target block being verified. According to the verification report, the verification label of the first verification block is adjusted to the second label; If the first verification block is not the last block to be verified in the current verification cycle, repeat the above operation; otherwise, end the block verification for the current verification cycle.

6. The method for verifying the correctness of historical ledger data according to claim 1, characterized in that, Determining each of the target blocks for any given verification period includes: Obtain the first height and the second height. The first height represents the number of blocks corresponding to all unverified basic blocks in the current verification cycle, and the second height represents the number of blocks corresponding to all target blocks that need to be verified in the current verification cycle. Based on the first height and the second height, consecutive base blocks are randomly selected from each base block as each target block; The smallest block height in each target block is: 0 < h ≤ (HK), where H, h, and K are all positive integers, H is the first height, and K is the second height.

7. A device for verifying the correctness of historical ledger data, characterized in that, The ledger nodes used for archiving data on the blockchain include: Data acquisition module: used to acquire the first block data and the first source data corresponding to the first verification block, wherein the first block data is the block data of the first verification block in the blockchain ledger maintained by the ledger node, and the first source data is the storage data corresponding to the first block data stored locally by the ledger node; all historical block verifications of the ledger node are completed by multiple verification cycles, and each verification cycle includes one or more target blocks; Data generation module: used to generate first verification data using the first source data based on the various indicator parameters of the first block data, wherein the first verification data includes all categories of the indicator parameters of the first block data; Data verification module: used to compare the various indicator parameters of the first verification data and the first block data to perform a first type of verification and generate a verification report; The first type of verification is the verification of the correctness of the ledger at the accounting node.

8. An electronic device, characterized in that, include: At least one processor, at least one memory, and computer program instructions stored in the memory, which, when executed by the processor, implement the method as described in any one of claims 1-6.

9. A storage medium storing computer program instructions thereon, characterized in that, The method as described in any one of claims 1-6 is implemented when the computer program instructions are executed by the processor.

Images