Historical account book consistency checking method and device, equipment and storage medium

Abstract

The invention belongs to the technical field of block chains, solves the problem that in the prior art, historical block data stored in a block chain node is maliciously tampered, and consequently the block chain data is incredible, and provides a historical account book consistency checking method and device, equipment and a storage medium. Comprising the steps that a check node obtains first block data from a block chain account book of each bookkeeping node according to a check rule, block heights corresponding to the first block data are the same, and then all index parameters of the first block data are compared, so that whether the block data for the same transaction in the block chain account book of each bookkeeping node is consistent or not is judged; if not, it is indicated that the block data corresponding to the transaction is tampered in the later period, it is guaranteed that the transaction data maintained by all the accounting nodes of the block chain is credible through the mode, and application and popularization of the block chain are facilitated.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a historical account book consistency verification method, device, equipment and storage medium. Background Art

[0002] Blockchain technology is built on a transmission network (also called a blockchain network). The distributed node devices in the transmission network (hereinafter referred to as nodes) run blockchain programs to generate block data based on preset consensus strategies, and use chain data structures to verify and store block data, ultimately realizing a data tamper-proof mechanism, providing a new, secure and reliable technical approach for business development.

[0003] In the prior art, data to be stored on the blockchain must be agreed upon by the blockchain consensus before it can be stored in the blockchain. Since the latest data stored on the blockchain is agreed upon by the blockchain consensus, each node with accounting authority on the blockchain has recorded the data, thereby ensuring that the data can be rolled back when the data is subsequently used without being tampered with. However, the administrator of each accounting node can modify the data stored in the node it manages, that is, the historical block data stored on the blockchain can be modified by its administrator. If the historical block data of a certain node is maliciously tampered with, then when the data is used subsequently, there will inevitably be a problem of data unreliability. Therefore, it is necessary to implement an effective tampering supervision mechanism for the historical block data stored on the blockchain to improve the credibility of blockchain data. Summary of the invention

[0004] In view of this, an embodiment of the present invention provides a historical ledger consistency verification method, device, equipment and storage medium to solve the problem of unreliable blockchain data caused by malicious tampering of historical block data stored in blockchain nodes in the prior art.

[0005] The technical solution adopted by the present invention is:

[0006] On the one hand, the present invention provides a historical ledger consistency verification method, characterized in that it is applied to each verification node of the blockchain, and the method includes:

[0007] In response to a data verification request for historical block verification, obtaining first block data corresponding to a first verification block of each accounting node, wherein the block heights of the first block data are the same;

[0008] Compare various index parameters of the first block data to perform a second type of verification and generate a verification report;

[0009] The second type of verification is a network-wide consistency verification of the first block data, and the verification report includes a verification log and abnormal block data.

[0010] Preferably, all historical block verifications on the blockchain include multiple verification cycles, each verification cycle includes one or more target blocks that need to be verified; wherein the first verification block is one of the target blocks in the current verification cycle.

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

[0012] Preferably, all unverified historical blocks are divided into multiple sampling segments according to a first number, and all historical blocks of a sampling segment are randomly selected as the target blocks of the current verification cycle, wherein the first number is the number of blocks that need to be verified in the current verification cycle.

[0013] Preferably, a plurality of blocks that need to be verified in the current verification cycle are randomly selected from all unverified blocks as the target blocks, and the block heights of the target blocks are adjacent or alternate.

[0014] Preferably, determining each of the target blocks in any verification cycle comprises:

[0015] Obtain the first height corresponding to each basic block of the blockchain that has not been verified in this round of verification and the second height composed of all the target blocks in the current verification cycle;

[0016] According to the first height and the second height, randomly selecting consecutive basic blocks from the basic blocks as the target blocks;

[0017] 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.

[0018] Preferably, the method further comprises:

[0019] Obtaining the total number of blocks corresponding to the target block that needs to be verified in the current verification cycle and the verification report of the first verification block corresponding to the target block currently verified;

[0020] According to the verification report, adjusting the verification tag of the first verification block to a second tag;

[0021] If the first check block is not the last block to be checked in the current check cycle, the above operation is repeated. If so, the block check in the current check cycle is terminated.

[0022] On the other hand, the present invention also provides a historical account consistency verification device, which is applied to each verification node of the blockchain, including:

[0023] A data acquisition module: used to respond to a data verification request for historical block verification, and to obtain first block data corresponding to a first verification block of each accounting node, wherein the block heights of the first block data are the same;

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

[0025] The second type of verification is a network-wide consistency verification of the first block data, and the verification report includes a verification log and abnormal block data.

[0026] On the other hand, the present invention further provides an electronic device, comprising: at least one processor, at least one memory, and computer program instructions stored in the memory, and when the computer program instructions are executed by the processor, any of the above-mentioned methods is implemented.

[0027] On the other hand, the present invention further provides a medium on which computer program instructions are stored, and when the computer program instructions are executed by a processor, any of the above methods is implemented.

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

[0029] The historical account book consistency verification method, device, equipment and storage medium provided by the present invention, the verification node obtains each first block data from the blockchain account book of each accounting node according to the verification rule, the block height corresponding to each first block data is the same, and then compares various indicator parameters of each first block data, so as to determine whether the block data for the same transaction in the blockchain account book of each accounting node is consistent. If it is inconsistent, it indicates that the block data corresponding to the transaction has been tampered with at a later stage. In this way, the transaction data maintained by each accounting node of the blockchain is guaranteed to be credible, which is conducive to the application and promotion of the blockchain. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] In order to more clearly illustrate the technical solution of the embodiment of the present invention, the drawings required for use in the embodiment of the present invention will be briefly introduced below. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work, and these are all within the protection scope of the present invention.

[0031] Figure 1 This is a flow chart of a method for obtaining consistency verification of historical account books in Example 1 of the present invention;

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

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

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

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

[0036] Figure 6 Schematic diagram of the structure of an electronic device in Embodiment 3 of the present invention. DETAILED DESCRIPTION

[0037] In order to make the purpose, technical solution and advantages of the embodiment of the present invention clearer, the technical solution in the embodiment of the present invention will be clearly and completely described in conjunction with the drawings in the embodiment of the present invention. It should be noted that, in this article, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply that there is any such actual relationship or order between these entities or operations. In the description of the present invention, it should be understood that the orientation or position relationship indicated by the terms "center", "upper", "lower", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inside", "outside", etc. is based on the orientation or position relationship shown in the drawings, which is only for the convenience of describing the present application and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as a limitation of the present invention. Moreover, the term "include", "comprise" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such a process, method, article or device. In the absence of further restrictions, the elements defined by the phrase "comprising..." do not exclude the existence of other identical elements in the process, method, article or device comprising the elements. If there is no conflict, the various features of the present invention and the embodiments can be combined with each other, all within the protection scope of the present invention.

[0038] Blockchain technology is built on a transmission network (also called a blockchain network). The 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 tamper-proof mechanism, providing a new, secure and reliable technical approach for business development.

[0039] Each node in the blockchain network can be a server or a terminal device. The server can be an independent physical server, a server cluster or a distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. The terminal device can be a smart phone, tablet computer, laptop computer, desktop computer, smart speaker, smart watch, etc., but is not limited to this. Each node can be directly or indirectly connected by wired or wireless communication, and this application is not limited here.

[0040] Example 1

[0041] See also Figure 1 , Figure 1 The historical account book consistency verification method in Example 1 of the present invention is applied to any accounting node and / or verification node of the blockchain. Every time a new block is generated in the blockchain, each accounting node will synchronize the new block to the account book it maintains. Each accounting node has the management authority corresponding to the account book it maintains. It can be understood that each accounting node can modify the account book data and stored source data maintained by it without the permission of other nodes. Each accounting node does not have the authority to manage the account books maintained by other nodes. It can be understood that accounting node A cannot access and modify the account book maintained by accounting node B. In order to prevent each accounting node in the blockchain from tampering with the historical block data in the account book it maintains, the method provided by the present invention includes:

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

[0043] Specifically, in order to prevent the historical block data and / or the source data corresponding to the block data in the blockchain from being tampered with, the present invention adopts regular or irregular verification of the block data and the corresponding source data of the account books maintained by each accounting node of the blockchain, including the correctness verification of the block data of the accounting node and the locally stored source data corresponding to the block data, and the consistency verification of the block data corresponding to the same block height in the account books of all accounting nodes on the blockchain, wherein the correctness verification is whether the source data stored locally by the accounting node matches the block data recorded by the accounting node in the blockchain account book. The correctness verification can be a self-checking program actively initiated by the accounting node, or it can be 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 are consistent. Based on the data verification request, the first block data of the block to be verified in each accounting node is obtained, and each accounting node obtains 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 authority can obtain the first block data of each accounting node according to its authority. Due to access permission issues, only each accounting node can obtain its own first source data corresponding to the first block data.

[0044] S2: performing a first type of verification on the first block data and the first source data corresponding thereto in the blockchain ledger maintained by the accounting node to obtain a first verification result, wherein the first type of verification is a correctness verification of the ledger of the accounting node, that is, whether the first block data is generated by the first source data;

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

[0046] S3: Perform a second type of verification on each of the first block data to obtain a second verification result, wherein the second type of verification is a full network consistency verification of the account book, and the block heights of each of the first block data are the same;

[0047] Specifically, in the ledger maintained by each accounting node on the blockchain, the block data (usually recorded as the hash value of the data) recorded for 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 the ledger of the accounting node in the blockchain has been tampered with. Therefore, the whole network consistency check will fail and the abnormal block information will be given. The abnormal block information includes block height, accounting node information, etc.

[0048] S4: Output a verification report according to the first verification result and / or the second verification result.

[0049] Specifically, if the node performing data verification is a bookkeeping node, it can perform the first type of verification of the node itself and the second type of verification of the consistency of the entire network, and output a verification report based on the first verification result and the second verification result. If only one of the first type of verification and the second type of verification is performed, the verification report is output based on the verification; if the node performing data verification is a non-bookkeeping node, it can only complete the second type of verification, and output a verification report based on the verification result of the second type of verification.

[0050] In one embodiment, when applied to the correctness verification of blockchain ledger data maintained by each accounting node and local storage data, the method includes:

[0051] Obtaining first block data and first source data corresponding to the first verification block, wherein the first block data is block data of the first verification block in a blockchain ledger maintained by a bookkeeping node, and the first source data is storage data corresponding to the first block data stored locally by the bookkeeping node;

[0052] Generate first verification data using the first source data according to 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;

[0053] Compare the first verification data and the first block data with each of the indicator parameters to perform a first type of verification and generate a verification report;

[0054] Among them, the first type of verification is the correctness verification of the ledger of the accounting node.

[0055] Specifically, based on the block height that needs to be verified, the accounting node obtains the first block data and the first source data corresponding to the block height, and then generates the first verification data from the first source data. If the blockchain ledger data of the accounting node does not exist and the source data stored locally has been tampered with, the first verification data and the first block data should be completely consistent, that is, the indicator parameter types 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 result.

[0056] In one embodiment, when a verification node performs a network-wide consistency check on a historical block of a blockchain ledger, the method includes:

[0057] In response to a data verification request for historical block verification, obtaining first block data corresponding to a first verification block of each accounting node, wherein the block heights of the first block data are the same;

[0058] Compare various index parameters of the first block data to perform a second type of verification and generate a verification report;

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

[0060] Specifically, according to the data verification request, the verification node obtains the first block data corresponding to the first verification block in the blockchain ledger maintained by each accounting node, and then compares the various indicator parameters of the first block data; if the first block data are 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, there are one or more blockchain ledgers that have tampered with the block data of the first verification block, and then a verification report is generated based on the comparison result.

[0061] In one embodiment, the verification report includes a verification log and abnormal block data.

[0062] Specifically, the verification log includes: verification time, verification method, block height and participating accounting node information, etc. The verification methods include random sampling, continuous sampling, active verification and automatic verification, etc. 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.

[0063] In one embodiment, the method further comprises:

[0064] S5: Obtain the total number of check blocks corresponding to the target block that needs to be checked in the current check cycle and the check report corresponding to the first check block;

[0065] S6: According to the verification report of the current verification block, adjusting the verification tag of the first verification block to a second tag;

[0066] S7: If the first check block is not the last block to be checked in the current check cycle, repeat the above operation. If so, end the block check in the current check cycle.

[0067] Specifically, each time a transaction is completed on the blockchain, the blockchain ledger maintained by each accounting node will add a block, that is, the block height of the blockchain will increase by 1. Transactions on the blockchain are continuous or intermittent. Therefore, the block height of the blockchain is constantly updated as transactions proceed, and historical blocks are constantly generated. It is necessary to periodically perform anti-tampering detection on the historical block data to prevent the accounting nodes from privately modifying their ledger data. As the number of blocks in the blockchain continues to increase, the number of blocks to be verified in each verification cycle can be fixed or can be continuously changed according to the current number of blocks to be verified. In one embodiment, the current verification cycle is assumed to be The number of blocks that need to be verified during the period is the preset number of verification blocks. For the convenience of description in this article, the first verification block is the block that has completed the latest verification. After the first verification block completes the first type of verification and / or the second type of verification, a corresponding verification report is generated, and then the verification tag of the first verification block is adjusted from the first tag corresponding to the unverified to the second tag corresponding to the verified. The first tag is used to identify the unverified blocks in the target blocks that need to be verified in the current verification cycle, and the second tag is used to identify the verified blocks in the target blocks that need to be verified in the current verification cycle. The second tag includes a first sub-tag for identifying abnormal blocks and a second sub-tag for identifying normal blocks. Then, it is determined whether the first verification is the last block that needs to be verified in the current verification cycle. If so, the current cycle verification is terminated. If not, 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.

[0068] In one embodiment, if it is determined that the first check block is not the last block that needs to be checked in the current check cycle, it is necessary to further determine whether the check time of the current check cycle has expired. If it has expired, the current check cycle is terminated, and the unchecked target blocks are included in the blocks to be checked in this round of verification, and the unchecked blocks will continue to be checked in subsequent check cycles; if the deadline of the current check cycle has not arrived, the new target blocks will continue to be checked.

[0069] In one embodiment, based on the number of second tags (recorded as the first tag number) and the number of target blocks (recorded 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 of the current verification cycle is counted, and the number of tags of the second tags is compared with the number of blocks of the target block. If the number of tags of the second tags is less than the number of blocks of the target block, the target block tamper-proof detection is continued until the number of first tags is equal to the first number, and the current verification cycle is ended.

[0070] In one embodiment, see Figure 2 , the S1 comprises:

[0071] S11: Obtain the calibration frequency and calibration data of the current calibration cycle;

[0072] S12: Determine the initiation time of the data verification request according to the verification frequency;

[0073] S13: Determine block information of the first check block of the data check request according to the check data;

[0074] S14: acquiring each of the first block data and the first source data according to the initiation time and the block information of the first verification block;

[0075] The verification data includes a first number of blocks that need to be verified in the current verification cycle, a second number of verified blocks, a third number of unverified blocks, and a first verification block of this verification.

[0076] Specifically, completing an anti-tampering detection on all historical block data is set as one round of detection. One round of detection includes at least one verification cycle. The verification frequency of each verification cycle can be set according to the transaction type to be completed by the blockchain. Taking the alliance chain corresponding to the wealth management subsidiary (wealth management subsidiary) and the sales agency as an example, the transactions of the wealth management subsidiary and the sales agency are usually completed in a specific time period and are intermittent. Therefore, the current verification cycle can be set in multiple intermittent times 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 times, so a trading day or a closed day can be used as a verification cycle; corresponding verification frequencies are set for different verification cycles, a data verification request is initiated based on the verification frequency, and the block information of the first verification block is determined according to the verification data, so as to obtain the first verification block corresponding to the block information, and the verification data includes the total number of blocks that need to be verified in the current verification cycle, the number of blocks that have completed verification and the number of blocks that have not been verified, and the first verification block of this verification determined according to the verification rules; the verification rules include random selection from unverified blocks and selection in sequence according to the block height order.

[0077] In one embodiment, the S11 includes:

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

[0079] S112: Generate the verification frequency of the current verification cycle and the first number of target blocks to be verified according to the total number of remaining blocks and the maximum number of blocks.

[0080] Specifically, when checking historical blocks at the beginning of the current check cycle, it is necessary to determine the number of blocks and the check frequency that need to be checked in the current check cycle. The number of blocks that need to be checked in the current check cycle is set as the first number, and each block that needs to be checked in the current check cycle is recorded as the target block; the first number is determined by the total number of remaining unchecked blocks in the blockchain and the maximum number of blocks corresponding to the highest check frequency in the current check cycle. The total number of remaining blocks is equal to the latest block height (number of blocks) of the blockchain minus the height of the block that has been checked (number of blocks). It should be noted that: if there is an unchecked block, the unchecked block height is increased by 1. Similarly, if there is a checked block, the unchecked block height is increased by 1. If there are 500 blocks with block height less than 1000 (including block A) and 300 blocks with block height between 1001 and 1500, the block height of block A in the verified blocks is 500, and the block height of block B in the unverified blocks is 700. Further, after determining the first number of blocks that need to be verified in the current verification cycle, the verification frequency is determined based on the first number. Furthermore, the time corresponding to the current verification cycle is 1 hour, and the maximum number of blocks that can be verified is 1000 blocks. At this time, the latest block height of the blockchain is 5050, and the number of blocks completed after the previous verification cycle is 4250. The first block number of the current verification cycle is 800, and the verification frequency is 4.5 seconds / time; if the number of blocks completed after the previous verification cycle is 4000, the first block number of the current verification cycle is 1000, and the verification frequency is 3.6 seconds / time.

[0081] It should be noted that: when performing tamper-proof verification on historical blocks in the ledgers of each accounting node on the blockchain, completing a tamper-proof verification on all historical blocks is recorded as one round of verification. After completing this round of verification, the next round of verification will start 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 will be continuously updated as the transaction proceeds, separating the first and last verification cycles of two adjacent rounds of verification is conducive to simplifying the verification data, improving the verification efficiency and preventing missed detection.

[0082] In one embodiment, the first number of target blocks are continuous blocks, and obtaining the first number of target blocks corresponding to the current verification cycle includes:

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

[0084] According to the first number, each of the basic blocks is divided into a plurality of sampling segments according to continuous block heights, and the number of the basic blocks corresponding to each of the sampling segments is the first number;

[0085] All the basic blocks of a sampling segment are randomly acquired as the target blocks.

[0086] Specifically, the block heights of the target blocks that need to be verified in the current verification cycle are continuous. For example, if the number of blocks that need 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. It should be understood that the block heights corresponding to the target blocks in the ledger are continuous, or that the target blocks are in the unverified block cluster, and all unverified historical blocks are rearranged in the order of block height. The target blocks are sequentially ordered into blocks corresponding to the first block, and the target blocks are continuous blocks in the first block sequence, such as: the block heights of the target blocks selected in the first verification cycle are 100 blocks consisting of 100-1099; the block heights of the target blocks selected in the second verification cycle are 100 blocks consisting of 1200-2199; then the continuous blocks selected in the third verification cycle can be 1000 target blocks consisting of 1-99, 1100-1199, and 2200-3001.

[0087] Furthermore, in order to facilitate the rapid determination of the first number of target blocks, the basic blocks that have not been verified in this round of verification are divided into a plurality of sampling segments according to the first number, and all the basic blocks of one sampling segment are randomly selected as the target blocks of the current verification cycle; by pre-dividing all the basic blocks into a plurality of continuous sampling segments, and then directly randomly selecting the sampling segments, it is ensured that the block heights of the target blocks verified each time are continuous.

[0088] In one embodiment, the first number of target blocks are continuous blocks, and obtaining the first number of target blocks corresponding to the current verification cycle includes:

[0089] Obtaining the first height corresponding to each basic block of the blockchain that has not been verified in this round of verification and the second height corresponding to the first number;

[0090] According to the first height and the second height, randomly selecting consecutive target blocks from the basic blocks;

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

[0092] Specifically, the block heights of the target blocks that need 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 that need to be verified in the current verification cycle. For example, if the number of unverified basic blocks is 5050, the first height is 5050, and the number of target blocks that need to be verified in the current verification cycle is 1000, then the second height is 1000; based on the first height and the second height, each continuous basic block corresponding to the second height is randomly selected as each target block, wherein the minimum block height of the target block is 0<h≤(HK), wherein H, h, and K are all positive integers, H is the first height, and K is the second height, thereby ensuring that K target blocks can be successfully selected.

[0093] In one embodiment, see Figure 3 , said S2 comprises:

[0094] S21: According to the first block data of the accounting node, retrieve the first source data stored in the accounting node;

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

[0096] S23: Compare each of the indicator parameters with the corresponding verification parameter, and generate the first verification result according to the comparison result.

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

[0098] Specifically, each accounting 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, use the first source data to generate various verification parameters corresponding to the various indicator parameters, and compare the various indicator parameters with the various verification parameters one by one. If they are consistent, the verification is passed, otherwise the first source data and / or the first block data have been tampered with; the various indicator parameters include ProposalHash, BlockHash, BlockDataHash and CommitHash, ProposalHash is a hash value generated based on the Proposal (proposal: an endorsement request for a node in a channel) data of the first source data, BlockHash is a unique identifier based on the block corresponding to the first source data, called a block hash, which is a digital fingerprint calculated from the transaction records and metadata of the block; BlockDataHash is a hash of all transactions contained in the block corresponding to the first source data, that is, a hash of the block data; CommitHash is a commit time hash of the block corresponding to the first source data.

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

[0100] In one embodiment, see Figure 4 , said S3 comprises:

[0101] S31: Obtain various index parameters of each of the first block data;

[0102] S32: Compare the index parameters of the first block data to perform consistency check to obtain the second check result.

[0103] Specifically, when performing the consistency check of the whole network ledger, the verification node obtains the first block data of the same block height of 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 first block data among the first block data involved in the comparison has been tampered with. If the indicator parameters of all the first block data are consistent, it means that the consistency check of the whole network ledger has passed, and a second verification result is generated based on the comparison result.

[0104] The historical account book consistency verification method of the present invention is that the verification node obtains each first block data from the blockchain account book of each accounting node according to the verification rule, the block height corresponding to each first block data is the same, and then compares various indicator parameters of each first block data, so as to judge whether the block data for the same transaction in the blockchain account book of each accounting node is consistent. If it is inconsistent, it indicates that the block data corresponding to the transaction has been tampered with at a later stage. In this way, the transaction data maintained by each accounting node of the blockchain is guaranteed to be credible, which is conducive to the application and promotion of the blockchain.

[0105] Example 2

[0106] See also Figure 5 The present invention further provides a historical account book consistency verification device based on the historical account book consistency verification method of Example 1, which is applied to each verification node of the blockchain, including:

[0107] A data acquisition module: used to respond to a data verification request for historical block verification, and to obtain first block data corresponding to a first verification block of each accounting node, wherein the block heights of the first block data are the same;

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

[0109] The second type of verification is a network-wide consistency verification of the first block data, and the verification report includes a verification log and abnormal block data.

[0110] In one embodiment, the verification of all historical blocks on the blockchain includes multiple verification cycles, each verification cycle includes one or more target blocks that need to be verified; wherein the first verification block is one of the target blocks in the current verification cycle.

[0111] In one embodiment, the block heights of the target blocks within the verification period are continuous.

[0112] In one embodiment, all unverified historical blocks are divided into multiple sampling segments according to a first number, and all historical blocks of a sampling segment are randomly selected as the target blocks of the current verification cycle, wherein the first number is the number of blocks that need to be verified in the current verification cycle.

[0113] In one embodiment, a plurality of blocks that need to be verified in the current verification cycle are randomly selected from all unverified blocks as the target blocks, and the block heights of the target blocks are adjacent or alternate.

[0114] In one embodiment, determining each of the target blocks in any verification cycle includes:

[0115] A height acquisition unit: acquiring a first height corresponding to each basic block of the blockchain that has not been verified in this round of verification and a second height corresponding to the first number;

[0116] A block selection unit: randomly selecting continuous target blocks from the basic blocks according to the first height and the second height;

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

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

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

[0120] A verification label changing module: used for adjusting the verification label of the first verification block to a second label according to the verification report;

[0121] The check block judgment module is used to repeat the above operation if the first check block is not the last block to be checked in the current check cycle, and if so, end the block check in the current check cycle.

[0122] The present invention provides a historical account book consistency verification device. The verification node obtains each first block data from the blockchain account book of each accounting node according to the verification rule. The block height corresponding to each first block data is the same. Then, various indicator parameters of each first block data are compared to determine whether the block data for the same transaction in the blockchain account book of each accounting node are consistent. If they are inconsistent, it indicates that the block data corresponding to the transaction has been tampered with at a later stage. In this way, the transaction data maintained by each accounting node of the blockchain is guaranteed to be credible, which is conducive to the application and promotion of the blockchain.

[0123] Example 3

[0124] The present invention provides an electronic device and a storage medium, see Figure 6 , comprising at least one processor, at least one memory and computer program instructions stored in the memory.

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

[0126] The memory may include a large capacity memory for data or instructions. By way of example and not limitation, the memory may include a hard disk drive (HDD), a floppy disk drive, a flash memory, an optical disk, a magneto-optical disk, a magnetic tape, or a universal serial bus (USB) drive or a combination of two or more of these. Where appropriate, the memory may include a removable or non-removable (or fixed) medium. Where appropriate, the memory may be inside or outside 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 a flash memory or a combination of two or more of these.

[0127] The processor implements any one of the historical account book consistency verification methods in the above-mentioned embodiments by reading and executing computer program instructions stored in the memory.

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

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

[0130] Bus includes hardware, software or both, and the parts of electronic equipment are coupled to each other.For example, but not limitation, bus may include accelerated graphics port (AGP) or other graphics bus, enhanced industrial standard architecture (EISA) bus, front side bus (FSB), hypertransport (HT) interconnection, industrial standard architecture (ISA) bus, infinite bandwidth interconnection, low pin count (LPC) bus, memory bus, micro channel architecture (MCA) bus, peripheral component interconnection (PCI) bus, PCI-Express (PCI-X) bus, serial advanced technology attachment (SATA) bus, video electronics standard association local (VLB) bus or other suitable bus or two or more of these combinations. In suitable cases, bus may include one or more buses. Although the embodiment of the present invention describes and shows a specific bus, the present invention considers any suitable bus or interconnection.

[0131] It should be clear that the present invention is not limited to the specific configuration and processing described above and shown in the figures. For the sake of simplicity, a detailed description of the known method is 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, and those skilled in the art can make various changes, modifications and additions, or change the order between the steps after understanding the spirit of the present invention.

[0132] The functional blocks shown in the above-described block diagram can be implemented as hardware, software, firmware or a combination thereof. When implemented in hardware, it can be, for example, an electronic circuit, an application specific integrated circuit (ASIC), appropriate firmware, a plug-in, a function card, etc. When implemented in software, the elements of the present invention are programs or code segments that are used to perform the required tasks. The program or code segment can be stored in a machine-readable medium, or transmitted on a transmission medium or a communication link by a data signal 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, optical fiber media, radio frequency (RF) links, etc. The code segment can be downloaded via a computer network such as the Internet, an intranet, etc.

[0133] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements 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 checking the consistency of historical accounts, characterized in that: Applied to each verification node of the blockchain, the method includes: In response to a data verification request for historical block verification, obtaining first block data corresponding to a first verification block of each accounting node, wherein the block heights of the first block data are the same; Compare various index parameters of the first block data to perform a second type of verification and generate a verification report; The second type of verification is a network-wide consistency verification of the first block data, and the verification report includes a verification log and abnormal block data.

2. The historical account book consistency verification method according to claim 1 is characterized in that: The verification of all historical blocks on the blockchain includes multiple verification cycles, each verification cycle includes one or more target blocks that need to be verified; wherein the first verification block is one of the target blocks in the current verification cycle.

3. The historical account book consistency verification method according to claim 1 is characterized in that: The block heights of the target blocks within the verification period are continuous.

4. The historical account book consistency verification method according to claim 2 or 3 is characterized in that: All unverified historical blocks are divided into multiple sampling segments according to a first number, and all historical blocks of one sampling segment are randomly selected as the target blocks of the current verification cycle, wherein the first number is the number of blocks that need to be verified in the current verification cycle.

5. The historical account book consistency verification method according to claim 2 is characterized in that: A plurality of blocks that need to be verified in the current verification cycle are randomly selected from all unverified blocks as the target blocks, and the block heights of the target blocks are adjacent or alternate.

6. The historical account book consistency verification method according to claim 2 is characterized in that: Determining each of the target blocks in any verification cycle includes: Obtain the first height corresponding to each basic block of the blockchain that has not been verified in this round of verification and the second height composed of all the target blocks in the current verification cycle; According to the first height and the second height, randomly selecting consecutive basic blocks from the basic blocks as the target blocks; The height of the smallest block in each target block is: 0<h≤(HK), wherein H, h, and K are all positive integers, H is the first height, and K is the second height.

7. The historical account book consistency verification method according to claim 1 is characterized in that: The method further comprises: Obtaining the total number of blocks corresponding to the target block that needs to be verified in the current verification cycle and the verification report of the first verification block corresponding to the target block currently verified; According to the verification report, adjusting the verification tag of the first verification block to a second tag; If the first check block is not the last block to be checked in the current check cycle, the above operation is repeated. If so, the block check in the current check cycle is terminated.

8. A historical account book consistency verification device, characterized in that: The verification nodes applied to the blockchain include: A data acquisition module: used to respond to a data verification request for historical block verification, and to obtain first block data corresponding to a first verification block of each accounting node, wherein the block heights of the first block data are the same; Data verification module: used to compare various index parameters of the first block data to perform the second type of verification and generate a verification report; The second type of verification is a network-wide consistency verification of the first block data, and the verification report includes a verification log and abnormal block data.

9. An electronic device, characterized in that: include: At least one processor, at least one memory and computer program instructions stored in the memory, when the computer program instructions are executed by the processor, implement the method according to any one of claims 1 to 7.

10. A storage medium having computer program instructions stored thereon, characterized in that: When the computer program instructions are executed by a processor, the method according to any one of claims 1 to 7 is implemented.

Images