A blockchain-oriented data disaster recovery method

Abstract

The application discloses a kind of data disaster recovery methods for blockchain, comprising: disaster detection, find the difference between the state of blockchain system reflected by business data set and the state of blockchain system reflected based on on-chain block, determine whether there is data disaster;Disaster recovery: based on the difference between the value list of verification credentials and the value list of key attribute set, and according to the transaction replay in on-chain block to eliminate or correct disaster data;Even complete global verification to business data set;Thus solve the problem that the state of blockchain system reflected by business data set and the state of blockchain system described based on on-chain block are inconsistent due to external active injection operation, that is, solve the data disaster recovery for blockchain, eliminate the disaster introduced by external injection operation to industry application business data set, so that the state of blockchain system reflected based on business data set and the state of blockchain system described based on on-chain block are consistent and compatible.

Description

Technical Field

[0001] This invention belongs to the field of data processing technology, and in particular relates to a data disaster recovery method for blockchain. Background Technology

[0002] For blockchain-based industrial applications, it is necessary and correct to separate the "chain state storage of the blockchain system" from the "storage of industrial application business data" (from a management and efficiency perspective, this is a necessary and correct approach), and to implement independent state, fault tolerance, and exception management. While external operations can directly access the industrial application's business data without disrupting the working state of the node where the stored system is located (meaning the block state crucial to that node is sound and compatible with the blockchain state maintained by other nodes), and will not disrupt or affect the normal operation of the blockchain system, the external "injection" operation breaks the consensus requirement for on-chain business transactions, disrupting the consistency between the "blockchain system state reflected in the business dataset" and the "current true state of the blockchain system." In other words, the industrial application's business data is introduced into a "disaster" due to the external injection operation.

[0003] Traditional measures or solutions for handling data management and data storage disaster recovery and backup are effective in ensuring the availability and handling of data anomalies of business data managed by the storage system. However, when the problem to be addressed is not just storage management or usage issues, but rather issues such as the state migration and evolution of different subsystems, as well as the state consistency between different subsystems, such as the relationship between the on-chain state system and the business data system of a blockchain, traditional measures and technical solutions are no longer suitable for the problems currently being studied.

[0004] Currently, the destructive behavior introduced into business datasets of industrial applications by external "injection" operations has not been clearly pointed out or discussed in existing research, nor has a clear handling mechanism been proposed or implemented. The reasons for the current situation are analyzed based on the following understanding of blockchain technology: 1) The fault-tolerant consensus mechanism of blockchain allows for the appearance of malicious or malfunctioning nodes; 2) With the support of distributed ledger technology, the consistency of node blocks can be guaranteed through the distribution of blocks.

[0005] The above viewpoints are indeed a correct understanding of blockchain technology. However, when using blockchain technology to achieve industrial applications, appropriate mechanisms or measures are needed to address the new problems faced by blockchain applications. Among them, the inherent (or native) consensus mechanism and distributed ledger of blockchain mentioned above can be regarded as "system-level" mechanisms, while solving the new problems or challenges caused by blockchain industrial applications requires the introduction of "application-level" mechanisms.

[0006] Blockchain technology is an emerging computing model that supports decentralization and business integrity. The potential for industrial applications of this technology is being continuously explored. However, in the process of supporting industrial applications, new problems or challenges will be encountered that need to be solved. For example, in the process of managing business data for industrial applications, where the blockchain addresses this issue, how to handle the consistency and compatibility between the blockchain on-chain state and the business data state in a mode that independently manages the on-chain state and the business data state is actually a problem that blockchain technology needs to solve in industrial applications but has not yet been solved. Summary of the Invention

[0007] To address the aforementioned issues, this invention proposes a data disaster recovery method for blockchain, resolving the inconsistency between the blockchain system state reflected in the business dataset and the blockchain system state depicted based on on-chain blocks caused by external active injection operations. Specifically, it eliminates the disasters introduced to industry application business datasets by external injection operations, or solves the data disaster recovery problem based on blockchain, ensuring that the blockchain system state reflected in the business dataset is consistent and compatible with the blockchain system state depicted based on on-chain blocks.

[0008] To achieve the above objectives, the technical solution adopted by this invention is: a data disaster recovery method for blockchain, comprising the following steps:

[0009] S10, Disaster Detection: This involves identifying discrepancies between the blockchain system state reflected in the business dataset and the blockchain system state reflected based on on-chain blocks to determine if a data disaster exists. First, all valid business transactions affecting the monitored business activities are screened from all transactions in all on-chain blocks, and a corresponding list of verification credential values ​​is constructed. Second, business data is accessed directly or via the blockchain API, and a list of key attribute values ​​is constructed accordingly. By comparing the list of verification credential values ​​and the list of key attribute values, the existence of disaster data in the business dataset is detected.

[0010] S20, Disaster Recovery, eliminates or corrects disaster data based on the differences between the verification credential value list and the key attribute set value list, and by replaying the transactions in reverse order within the on-chain block.

[0011] S30, global verification of business data, sequential replay of transactions in on-chain blocks, construction of all business record instances created and updated by all business activities, verification of all business records in the business dataset; discovery of existing business data errors and the ability to eliminate discrepancies and restore the correct dataset;

[0012] Through disaster detection, disaster recovery, and global verification of business data, the state of the blockchain system reflected by the centralized business data is made consistent with the state of the blockchain system reflected by the on-chain blocks and the packaged business exchanges.

[0013] Furthermore, the disaster detection includes the following steps:

[0014] S11, Determine the detection indicators: The detection basis is determined to be each block on the blockchain and each transaction encapsulated in each block. The detection object is determined to be the business dataset of the industry application. The business dataset consists of various business records, and each business record is a set of all attribute values ​​representing the state of a business activity. For a certain business record that describes the occurrence or execution of a business activity, there are two relationships between it and other business records of the same business activity: Relationship 1: In the set of all these attributes, there exists one or more attributes that can uniquely identify the business record in the business dataset; Relationship 2: For the business records of the business activity, there is no one or more attributes that can distinguish each business record from other business records in the dataset. The one or more attributes selected to distinguish different business records are called the key attribute set.

[0015] S12, Process business records that satisfy the aforementioned first type of relationship. The information table associated with the business activity has a set of key attributes that can uniquely distinguish each business record. Construct a list of verification voucher values ​​for relationship one for disaster verification.

[0016] S13, Process business records that satisfy the aforementioned second type of relationship. If there is no key attribute set that can uniquely distinguish each business record in the business dataset, construct a list of verification credential values ​​for relationship two for disaster verification.

[0017] S14, Disaster Verification: Based on the verification credential value list constructed above, examine the business dataset being verified. If the list of key attribute values ​​for all business records in the business dataset is not equal to the verification credential value list, then a disaster exists in the business dataset. That is, before the last block that constructed the verification credential value list, the business dataset was injected with external operations, and the effects of all external injection operations did not cancel each other out, leaving a disaster in the dataset, causing the blockchain system state reflected by the business data in the business dataset to be inconsistent with the blockchain system state reflected by the on-chain blocks.

[0018] Furthermore, when determining the detection index in step S11, regardless of which of the two relationships mentioned above exists between the business records, the detection index determined to detect whether the state of the blockchain system reflected by the business data in the business dataset is consistent with the state of the blockchain system reflected by the on-chain blocks is: one or more attributes that characterize the state of business activities. For example, the primary key attribute that does not allow null values ​​in a certain business information table can be a detection index for one attribute.

[0019] For the business records in the business dataset associated with the above business activities that satisfy the first type of relationship, the requirement is to find the smallest set of attribute combinations that can uniquely distinguish each business record; for the business records that have the second type of relationship, the solution is to select a suitable combination of multiple attributes based on the business details, and then group all business records according to the values ​​of the selected combination of multiple attributes.

[0020] The attribute or combination of attributes selected to distinguish different business records is called the key attribute set. For the relationship between the first type of business records, a key attribute set is found, and all business records have different values ​​of the key attribute set. For the relationship between the second type of business records, a key attribute set is selected according to the business activity to effectively classify the records in the entire business dataset.

[0021] Furthermore, in step S12, business records that satisfy the aforementioned first type of relationship are processed. The information table associated with the business activity contains a set of key attributes that uniquely distinguish each business record. A list of verification credential values ​​for relationship one is constructed for disaster recovery verification, including the following steps:

[0022] S121, Define an empty list of verification vouchers;

[0023] S122, sequentially traverse all blocks on the chain, starting from the block with a block height of 1 and continuing up to the current block height. For each block, perform the following operation of traversing all transactions within the block.

[0024] S123, Traverse all transactions in each block, that is, from the first transaction in the transaction list of the selected block to the last transaction in the transaction list, and perform the replay verification operation of the historical transactions below;

[0025] S124, determine whether the current business transaction is the business activity that needs to be verified, that is, whether the transaction will modify the business records in the business information table associated with the business activity, involving adding, deleting or changing business records; if not, return to step S123 to perform the judgment of the next transaction; if yes, continue to perform the following steps.

[0026] S125, Determine whether the current business transaction has been successfully executed. If so, change the constructed verification document value list according to the executed operation. If the current business transaction has not been successfully executed, keep the constructed verification document value list unchanged.

[0027] S126, Return to step S123 and continue processing the next transaction in the current block;

[0028] S127, return to step S122 and continue processing the next block on the chain until the specified block height or the latest block on the chain is reached.

[0029] Furthermore, in step S124, business transactions unrelated to the currently verified business activity are excluded by verifying the to address of the transaction.

[0030] Furthermore, in step S13, for business records satisfying the aforementioned second type of relationship, if no key attribute set can uniquely distinguish each business record in the business dataset, a list of verification credential values ​​for relationship two is constructed for disaster verification, including the following steps:

[0031] S131, Define an empty list of verification credentials;

[0032] S132, sequentially traverse all blocks on the chain, starting from the block with a block height of 1 and continuing up to the current block height. For each block, perform the following operation of traversing all transactions within the block.

[0033] S133, Traverse all transactions in each block, that is, from the first transaction in the transaction list of the selected block to the last transaction in the transaction list, and perform the replay verification operation of the historical transactions below;

[0034] S134, determine whether the current business transaction is the business activity that needs to be verified, that is, whether the transaction will modify the business records in the business information table associated with the business activity, involving adding, deleting or changing business records. If not, return to step S133 to perform the judgment of the next transaction. If yes, continue to perform the following steps.

[0035] S135, determine whether the current business transaction was successfully executed. If not, do not adjust the constructed verification voucher value list; if the business transaction was successfully executed, then based on the number of business records affected by the business transaction in the function return value obtained from parsing the transaction receipt, perform the operation according to each business operation type:

[0036] Obtain the transaction hash from the valid business transaction details obtained in step S134; obtain the transaction receipt of the current transaction based on the transaction hash; based on the contract function corresponding to the business transaction obtained in step S134, parse the output information in the transaction receipt obtained above using the ABI of the contract function, and determine whether the business transaction was successfully executed based on the parsing result; based on the return values ​​of other functions obtained from parsing the output information in the transaction receipt, obtain the number of business records affected by the operation executed by the business transaction; based on the parsing result of the business transaction input information parsing in step S134, and combined with the number of business records affected by the business transaction operation, adjust the composition of the verification voucher value list according to the operation category of the business transaction;

[0037] Add a new operation: For the number of business records for each key attribute set whose values ​​are added, add the corresponding number of values ​​for that one or more attribute combinations to the verification voucher value list;

[0038] Deletion operation: For the number of business records whose values ​​for each key attribute set have been deleted, remove the corresponding number of values ​​for that key attribute set from the constructed verification voucher value list;

[0039] Update operation: For the number of business records whose old values ​​have been updated for each key attribute set, change the old value of the corresponding number of key attribute sets to the new value from the constructed verification voucher value list;

[0040] S136, Return to step S133 and continue processing the next transaction in the current block;

[0041] S137, return to step S132 and continue processing the next block on the chain until the specified block height or the latest block on the chain is reached.

[0042] Furthermore, in step S14, the disaster verification includes the following steps:

[0043] S141, obtain the list of key attribute set values ​​for all business records in the business dataset of interest via the API provided by the blockchain; the key attribute set values ​​are stored as tuples in the list.

[0044] S142, compare the verification voucher value list obtained from the constructed verification voucher value list with the key attribute set value list constructed in S141 to see if they are consistent;

[0045] If they are consistent, it is considered that there is no disaster in the business dataset, that is, the state of the blockchain system reflected by the business data in the business dataset is consistent with the state of the blockchain system reflected by the on-chain blocks.

[0046] If there is a discrepancy, the business data in the business dataset cannot accurately reflect the current state of the blockchain system, and there is disaster information in the business data, requiring disaster recovery operations to be performed.

[0047] Furthermore, for cases where the key attribute sets of each business record in the business dataset have unique values, i.e., the relationship between business records belongs to relation one, disaster recovery includes the following steps:

[0048] S211, Delete all business records from the business dataset whose key attribute set values ​​are in the key attribute value list but not in the verification voucher value list.

[0049] S212, reconstruct the business records whose key attribute set values ​​are in the verification certificate value list but not in the key attribute set value list constructed from all business records in the business dataset, and add the reconstructed business records to the business information table; the reconstruction of business records needs to be based on the valid transactions in the on-chain blocks.

[0050] Furthermore, for scenarios where the key attribute set of each business record in the business dataset cannot uniquely distinguish the business records in the dataset, i.e., the relationship between the business records belongs to relation two, disaster recovery includes the following steps:

[0051] S221, When a key attribute set value exists in the key attribute set value list but does not exist in the verification voucher value list, perform an external operation to delete the business record with the key attribute set value of the specified value from the business dataset;

[0052] S222, when a certain key attribute set value appears more often in the key attribute set value list than in the verification credential value list, assuming the key attribute set value is 'a', compare a list consisting of all business records in the business dataset with all such key attribute set values ​​of 'a' and another list consisting of all business records with key attribute set values ​​of 'a' resulting from the execution of historical transactions on the chain up to the current block; and delete all business records in the first list that are not in the second list from the business dataset.

[0053] S223, When there is a case where the value of the key attribute set exists in the value list of the verification certificate but does not exist in the value list of the key attribute set, start from the current block and traverse the on-chain blocks and the packaged transactions in reverse order to construct the business record of the specific key attribute set value. Traverse in reverse order until all attribute values ​​of the corresponding business record are determined, and add the reconstructed business record to the business dataset.

[0054] S224, when a key attribute set value appears less often in the key attribute set value list than in the verification credential value list, compare a list consisting of all business records in the business dataset with all key attribute set values ​​of 'a' and another list consisting of all business records with key attribute set values ​​of 'a' resulting from the execution of historical on-chain transactions up to the current block; and add all business records in the second list that are not in the first list to the business dataset.

[0055] Furthermore, the method for global verification of the business data includes the following steps:

[0056] S31, Define an empty business dataset instance;

[0057] S32, sequentially traverse all blocks on the chain from the starting block to the current block, sequentially traverse all transactions in the transaction list of each block, and execute valid business transactions one by one;

[0058] S33, based on the contract ABI and contract function ABI, parse the input information of the business transaction, parse the output information of the transaction receipt, obtain the input parameters and output parameters of the successfully executed business transaction, and then perform operations such as inserting, deleting, and updating attribute values ​​on the constructed business data instance in sequence.

[0059] S34, jump to step S32, and repeat until all blocks and all valid transactions have been traversed to obtain a business dataset instance that correctly reflects the current state of the blockchain system;

[0060] S35, using the business dataset instance constructed above, verify the business dataset that has been compromised due to external injection operations, and eliminate data errors.

[0061] The beneficial effects of adopting this technical solution are:

[0062] This invention addresses the data disaster problem in blockchain-based industrial applications caused by external injection operations, proposing a solution for disaster detection, disaster recovery, and global verification of business data. The invention proposes constructing a key attribute set to identify and differentiate business records, serving as a data disaster detection indicator. Based on this key attribute set, the invention maps on-chain business transactions to a list of verification credential values. Changes in the constituent units of the verification credential value list (such as adding or removing units) directly reflect on-chain business transactions (such as adding, deleting, or modifying business records). The invention proposes a rapid disaster detection mechanism: comparing the number of units and values ​​in the verification credential value list constructed from on-chain business transactions and the key attribute set value list constructed from the business dataset to quickly locate data disasters in the dataset. This invention proposes a rapid disaster recovery mechanism. This mechanism utilizes data disasters detected by disaster detection, and then resolves them by deleting redundant business records from the business dataset and by reconstructing missing business records in the business dataset by traversing blocks and business transactions in reverse order starting from the current block. It also employs a transaction backtracking termination strategy: stopping upon discovery (for business transactions, this is an insertion operation) and stopping upon completion (for business transactions, this is an update operation). To ensure the completeness of this invention, a method for global verification of business data is also provided at the end of the technical solution.

[0063] This invention proposes an efficient mechanism for detecting data disasters caused by external injection operations, specifically, efficiently identifying discrepancies or contradictions between the blockchain system state reflected in business data and the blockchain system state reflected in on-chain blocks and exchanges. This invention provides a technical solution for efficiently resolving data disaster problems caused by external injection operations, namely data disaster recovery, by performing add, delete, and modify operations on the industry application business dataset to eliminate discrepancies or contradictions between the blockchain system state reflected in business data and the blockchain system state reflected in on-chain blocks and exchanges. To facilitate a comprehensive review of the integrity and availability of industry application business datasets, this invention proposes a global verification method for business datasets. Attached Figure Description

[0064] Figure 1 This is a schematic diagram of a data disaster recovery method for blockchain according to the present invention;

[0065] Figure 2 This is a flowchart illustrating the disaster verification process under Relationship 1 in this embodiment of the invention.

[0066] Figure 3 This is a flowchart illustrating the disaster verification process under Relationship Two in this embodiment of the invention.

[0067] Figure 4 This is a disaster recovery flowchart for scenario one in an embodiment of the present invention;

[0068] Figure 5 This is a flowchart illustrating the disaster recovery process under Relationship Two in this embodiment of the invention. Detailed Implementation

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

[0070] External operations performed through the API interfaces provided by the blockchain system, i.e., injection operations, are considered unauthorized operations. These operations can be further divided into two types: "passive" and "active." "Passive" injection operations only perform "read" operations and do not damage or affect the business information in the industry application business dataset maintained by the blockchain, nor do they cause inconsistencies between the "blockchain system state reflected in the business dataset" and the "real state of the blockchain system." However, "active" injection operations will modify (add, delete, or update, etc.) the business records in the industry application business dataset, causing inconsistencies and incompatibility between the "blockchain system state reflected in the business dataset" (which is also the system state of the industry application, i.e., the values ​​of the various business-related attributes of the industry application system represent its application business state) and the "blockchain system state depicted by the blockchain system based on on-chain blocks."

[0071] Based on the above findings, the technical solution proposed in this invention will solve the problem of inconsistency between the "blockchain system state reflected by the business dataset" and the "blockchain system state depicted based on on-chain blocks" caused by external "active" injection operations. That is, it will eliminate the "disaster" introduced to the business dataset of industrial applications by external "injection" operations, or solve the recovery of "data disaster" based on blockchain, so that the "blockchain system state reflected by the business dataset" and the "blockchain system state depicted based on on-chain blocks" are consistent and compatible.

[0072] In this embodiment, see Figure 1 As shown, this invention proposes a data disaster recovery method for blockchain, including the following steps:

[0073] S10, Disaster Detection: This involves identifying discrepancies between the blockchain system state reflected in the business dataset and the blockchain system state reflected based on on-chain blocks to determine if a data disaster exists. First, all valid business transactions affecting the monitored business activities are screened from all transactions in all on-chain blocks, and a corresponding list of verification credential values ​​is constructed. Second, business data is accessed directly or via the blockchain API, and a list of key attribute values ​​is constructed accordingly. By comparing the list of verification credential values ​​and the list of key attribute values, the existence of disaster data in the business dataset is detected.

[0074] S20, global verification of business data, sequential replay of transactions in on-chain blocks, construction of all business record instances created and updated by all business activities, verification of all business records in the business dataset; discovery of existing business data errors and the ability to eliminate discrepancies and restore the correct dataset;

[0075] Through disaster detection, disaster recovery, and global verification of business data, the state of the blockchain system reflected by the centralized business data is made consistent with the state of the blockchain system reflected by the on-chain blocks and the packaged business exchanges.

[0076] As an optimized solution to the above embodiments, the disaster detection includes the following steps:

[0077] S11, Determine the detection indicators: The detection basis is each block on the blockchain and each transaction encapsulated in each block. The detection object is the business dataset of the industry application. The business dataset consists of business records, and each business record is a set of all attribute values ​​representing the state of a business activity. For a certain business record that describes the occurrence or execution of a business activity, there are two relationships between it and other business records of the same business activity: Relationship 1: In the set of all these attributes, there exists one or more attributes that can uniquely identify the business record in the business dataset. For example, in the design of a data table, the definition of "primarykey" (primary key field) with the requirement of "unique" can uniquely distinguish each business record. Relationship 2: For the business records of a business activity, there is no one or more attributes that can distinguish each business record from other business records in the dataset. For example, if there is a certain business record in a certain business dataset, the values ​​of each attribute of this business record are the same in one (or more) business records in the business dataset. The attribute or combination of attributes selected to distinguish different business records is called the key attribute set.

[0078] By handling the above two types of business record relationships, selecting one attribute or a combination of attributes, and combining it with the historical transaction replay verification method proposed later, it is possible to complete the task of judging whether the blockchain system state reflected by the business dataset is consistent with the blockchain system state reflected based on on-chain blocks. Furthermore, in the event of a business data disaster, executing the historical transaction replay recovery method can reconstruct the correct business dataset that correctly reflects the current blockchain system state.

[0079] The business records in the business information table associated with the business activities reflect the cumulative results of business operations executed by contracts deployed on the blockchain and externally initiated injection operations. Therefore, all business records in this business information table are only objects to be checked. Verification credentials are constructed from all blocks on the chain to verify whether the business records in the current business information table correctly reflect the true state of the current blockchain system. This involves constructing a list of values ​​for the key attribute set selected in the previous step, evolving it to the current block's values. This list is called the verification credential value list, and the values ​​of the key attribute set in the list exist in tuple form. It is important to note that the "list" used here refers to a concept in the sense of data unit organization, allowing duplicate units (values). A "set" is not used because the latter does not support duplicate units. Allowing duplicate units is crucial for business activities that support the second type of relationship between business records in the business information table.

[0080] S12, Process business records that satisfy the aforementioned first type of relationship. The information table associated with the business activity has a set of key attributes that can uniquely distinguish each business record. Construct a list of verification voucher values ​​for relationship one for disaster verification.

[0081] S13, Process business records that satisfy the aforementioned second type of relationship. If there is no key attribute set that can uniquely distinguish each business record in the business dataset, construct a list of verification credential values ​​for relationship two for disaster verification.

[0082] S14, Disaster Verification: Based on the verification credential value list constructed above, examine the business dataset being verified. If the list of key attribute values ​​for all business records in the business dataset is not equal to the verification credential value list, then a disaster exists in the business dataset. That is, before the last block that constructed the verification credential value list, the business dataset was injected with external operations, and the effects of all external injection operations did not cancel each other out, leaving a disaster in the dataset, causing the blockchain system state reflected by the business data in the business dataset to be inconsistent with the blockchain system state reflected by the on-chain blocks.

[0083] Preferably, when determining the detection index in step S11, regardless of which of the two relationships mentioned above exists between the business records, the detection index determined to detect whether the state of the blockchain system reflected by the business data in the business dataset is consistent with the state of the blockchain system reflected by the on-chain blocks is: one or more attributes that characterize the state of business activities. For example, the primary key attribute that does not allow null values ​​in a certain business information table can be a detection index for one attribute.

[0084] For the business records in the business dataset associated with the above business activities that satisfy the first type of relationship, the requirement is to find the smallest set of attribute combinations that can uniquely distinguish each business record (optimal if only "one attribute" can be used to uniquely distinguish them). For the second type of relationship between business records, a suitable combination of multiple attributes is selected based on the business details, which can group all business records according to the values ​​of the selected combination of multiple attributes. Of course, selecting a combination of all attributes of the business records can distinguish the business records in the business data table associated with the business activities to the greatest extent. However, in practice, it is necessary to comprehensively consider the effectiveness of the attribute combination selection and the computational efficiency of detecting whether there is a disaster in the business data to select an effective combination of multiple attributes.

[0085] One or more attributes are selected to distinguish different business records, i.e., the key attribute set; for the relationship between the first type of business records, a key attribute set is found, and all business records have different values ​​of the key attribute set; while for the relationship between the second type of business records, a key attribute set is selected according to the business activity to effectively classify the records in the entire business dataset.

[0086] Preferred, such as Figure 2 As shown, in step S12, business records that satisfy the aforementioned first type of relationship are processed. The information table associated with the business activity has a set of key attributes that can uniquely distinguish each business record. A list of verification voucher values ​​for relationship one is constructed for disaster verification, including the following steps:

[0087] S121, Define an empty list of verification credentials, denoted as verify_credential_value_list, which is initialized to empty "[]";

[0088] S122, Traverse all blocks on the chain, starting from the block with a block height of 1 and continuing up to the current block height. For each block, perform the following operation of traversing all transactions within the block.

[0089] S123, sequentially traverse all transactions in each block, that is, from the first transaction in the transaction list of the selected block to the last transaction in the transaction list, and perform the replay verification operation of the historical transactions below;

[0090] S124. Determine whether the current business transaction is the business activity that needs to be verified, that is, whether the transaction will modify the business records in the business information table associated with the business activity, involving adding, deleting or changing business records. If not, return to step S123 to perform the judgment of the next transaction. If yes, continue to perform the following steps.

[0091] S125, Determine whether the current business transaction has been successfully executed. If so, change the constructed verification credential value list according to the executed operation (i.e., the business transaction that triggered the call to the contract function); if the current business transaction has not been successfully executed, keep the constructed verification credential value list unchanged.

[0092] S126, Return to step S123 and continue processing the next transaction in the current block;

[0093] S127, return to step S122 and continue processing the next block on the chain until the specified block height or the latest block on the chain is reached.

[0094] For step S125 in the above technical solution, it is necessary to understand the meaning of "successful transaction execution," which means that no system or platform-level exceptions or errors occurred during the transaction execution process. However, analyzing from the client's motivation (or purpose) for triggering the contract (calling the contract function), if the result of this transaction is the result of the expected action, such as the contract calling "add" a business record, and the result of the transaction execution is also the addition of a business record to the business information table, then the transaction is a "successful transaction." If, for some reason, the transaction execution result does not insert the relevant business record into the business information table, then the transaction is a "failed transaction." Reasons for transaction failure include the fact that the value of the "key attribute set" identifying the business record to be added has already appeared in a record in the business information table. Because the attribute (a combination of one or more attributes, i.e., the key attribute set) that uniquely identifies the business record must have a unique value, the record cannot be added. For successful transactions, the construction of the verification voucher changes the unit composition of the "verification voucher value list" according to different operations. The construction of the verification voucher value list follows the following scheme:

[0095] Adding a new business record: This adds the value of the "key attribute set" (viewed as a tuple) of the newly added business record to the voucher list verify_credential_value_list. From the perspective of how to record the "add" action, adding a value (the value of the "key attribute set" of the newly added business record) to the "verification voucher value list" uniquely corresponds to the operation of adding a new business record.

[0096] "Delete" business record: Removes the value of the "key attribute set" of the currently deleted business record from the voucher list. Similarly, removing a value of a "key attribute set" from the "verification voucher value list" uniquely corresponds to the current "delete" business record operation.

[0097] When updating a business record, the system first determines whether the value of the "key attribute set" of the business record has been updated. If so, the corresponding old value in the voucher list is changed to the new value. If not, there is no need to change the unit composition or value of the voucher list. Because a "change" operation may change the value of the selected "key attribute set" or the values ​​of other attributes in the business record, inserting a value into the "verification voucher value list" to correspond to (characterize) the current "update" operation is feasible. However, this mechanism requires selecting all attributes of the business record to form the "key attribute set," which serves as a detection indicator for external "injection" operations. This mechanism is difficult to verify external "injection" operations (because it requires replaying all historical transactions) and is inefficient in detecting data "disasters." Therefore, for "update" business operations (business transactions), the mechanisms and solutions for "disaster" detection and recovery below only focus on operations where the "key attribute set" is "updated."

[0098] In step S124, business transactions that are not related to the currently verified business activity (associated business information table) are excluded by verifying the transaction's to address (i.e., the address of the deployed smart contract, which uniquely identifies a contract).

[0099] It is important to note that business transactions packaged into blocks may call system contracts (i.e., pre-set contracts of the blockchain platform, which can be triggered without user deployment) or user-deployed contracts to execute related business activities. Therefore, do not miss any business transactions caused by the call of any type of contract (system contract or user contract) that can modify business records in the business information table. In other words, there is usually more than one legitimate "to" address. So do not miss any user contracts or system contracts.

[0100] It is important to note that during the operation of industrial applications, there may be upgrade operations of business contracts (business activities executed by different versions of deployed contracts are associated with the same business information data table), and multiple deployments of contracts with the same name (such as version upgrades). Each version will correspond to a different contract address. Therefore, when constructing the list of verification credential values, do not omit any business activities caused by any version of the business contract. That is, the list of valid "to" addresses should include the contract addresses of all versions of deployed contracts.

[0101] It is important to note that all transactions packaged into the blockchain block are transactions that change the state of the blockchain system and require consensus (and have been agreed upon). They do not include business transactions that do not require consensus, such as querying or retrieving business information tables. Therefore, all contract calls to the above-mentioned legitimate "to" addresses (contract addresses) must be business operations that change the business records in the business data information tables associated with the business activities, and of course, they also change the state of the blockchain system.

[0102] Some exceptions need to be considered, namely, transactions that fail are also recorded (more accurately, "erroneous" transactions) and packaged into blocks. There are various reasons for transaction failure, such as insufficient gas, business logic errors (such as accessing objects that do not exist on the chain), etc. For these transactions, since the transaction did not actually occur (the result of the transaction execution was not recorded on the chain or the executed part of the transaction was rolled back, and the state of the entire blockchain system did not change), these failed transactions need to be excluded when constructing the list of verification credential values.

[0103] Preferably, in step S13, as follows Figure 3 As shown, for business records satisfying the aforementioned second type of relationship, if there is no key attribute set that can uniquely distinguish each business record in the business dataset, a list of verification credential values ​​for relationship two is constructed for disaster verification, including the following steps:

[0104] S131, Define an empty list of verification credentials, denoted as verify_credential_value_list, which is initialized to empty "[]";

[0105] S132, sequentially traverse all blocks on the chain, starting from the block with a block height of 1 and continuing up to the current block height. For each block, perform the following operation of traversing all transactions within the block.

[0106] S133, Traverse all transactions in each block, that is, from the first transaction in the transaction list of the selected block to the last transaction in the transaction list, and perform the replay verification operation of the historical transactions below;

[0107] S134, determine whether the current business transaction is the business activity that is required to be verified, that is, whether the transaction will modify the business records in the business information table associated with the business activity, involving adding, deleting or changing business records. If not, return to step S133 to perform the judgment of the next transaction. If yes, continue to perform the following steps.

[0108] S135, determine whether the current business transaction was successfully executed. If not (i.e., the contract call did not perform any changes to the business dataset for related reasons), then do not adjust the constructed verification voucher value list; if the business transaction was successfully executed, then based on the number of business records affected by the business transaction (addition, deletion, modification, etc.) in the function return value obtained from parsing the transaction receipt, perform the operations separately for each business operation type:

[0109] Obtain the transaction hash from the valid business transaction details obtained in step S134; obtain the transaction receipt of the current transaction based on the transaction hash; based on the contract function corresponding to the business transaction obtained in step S134, parse the output information in the transaction receipt obtained above using the ABI of the contract function, and determine whether the business transaction was successfully executed based on the parsing result; based on the return values ​​of other functions obtained from parsing the output information in the transaction receipt, obtain the number of business records affected by the operation executed by the business transaction; based on the parsing result of the business transaction input information parsing in step S134, and combined with the number of business records affected by the business transaction operation, adjust the composition of the verification voucher value list according to the operation category of the business transaction;

[0110] Add a new operation: For the number of business records for which the values ​​of the key attribute set have been added, add the corresponding number of values ​​of the one or more attribute combinations to the verification voucher value list;

[0111] Deletion operation: For the number of business records whose values ​​of the key attribute set have been deleted, remove the corresponding number of values ​​of that key attribute set from the constructed verification voucher value list;

[0112] Update operation: For the number of business records whose old values ​​of the key attribute set have been updated, change the old value of the corresponding number of the key attribute set to the new value from the constructed verification voucher value list;

[0113] S136, Return to step S133 and continue processing the next transaction in the current block;

[0114] S137, return to step S132 and continue processing the next block on the chain until the specified block height or the latest block on the chain is reached.

[0115] This applies to the "Second Scenario"—where there is no "key attribute set" ("one attribute" or "a combination of multiple attributes") that can uniquely distinguish each business record in the business dataset. However, as mentioned earlier, the effective "key attribute set" selected based on business activity details can effectively group (classify) all business records in the business dataset. Unlike the First Scenario, where the value of the "key attribute set" examined for each business record in the business dataset is unique, thus uniquely distinguishing each business record, the units in the verification credential value list constructed from the transactions packaged in the on-chain block must also have different values. However, for the Second Scenario, the "key attribute set" (a combination of multiple attributes) of interest cannot uniquely distinguish the business records in the business dataset; that is, it is permissible for two or more business records to have the same value for the "key attribute set." Correspondingly, for this scenario, there should also be two or more verification credentials with the same value in the verification credential value list constructed from the transactions packaged in the on-chain block. In other words, the value of the "key attribute set" is allowed to appear repeatedly.

[0116] Because of the above differences, in step S125, which constructs the verification voucher value list for the first scenario, this step only relies on the judgment of "whether the contract transaction was successfully executed" (based on the parsed transaction receipt information) and combines it with the function type of the contract transaction execution (add, delete, or update). The verification voucher value list can then be constructed using the parsed contract function input parameters. However, for the second scenario, "whether the contract transaction was successfully executed" is only a condition for judging whether the verification voucher value list needs adjustment (adjustment is needed if successful, and not needed if unsuccessful). However, "how to adjust" the verification voucher value list requires further information from the parsed transaction receipt, namely, the information in the function return value regarding the number of newly added business records, the number of deleted business records, and the number of updated business records, to adjust the verification voucher value list.

[0117] Regarding step S135 of the above scheme, the "add" business record operation usually only adds one record, unless a batch import operation is performed, i.e., a batch add operation. In the first scenario, for the batch import operation, the business records added in batches also each have a unique "key attribute set" value. However, in the second scenario, multiple batch-added business records may have the same "key attribute set" value. As mentioned in step S135, it is necessary to add the corresponding number of "key attribute set" values ​​to the constructed verification voucher value list, even though these added values ​​are the same. For the "delete" business record operation, there may be multiple records in the business dataset that meet the constraints. Assuming that the search condition is a specific "key attribute set", there may be multiple business records that meet the search condition. Therefore, it is necessary to remove the value of the "key attribute set" of the removed business records one by one from the constructed verification voucher value list. That is, it is necessary to ensure that the number of records removed from the business dataset is equal to the number of values ​​of a certain "key attribute set" removed from the verification voucher value list.

[0118] Preferably, in step S14, the disaster verification includes the following steps:

[0119] S141, obtain the list of key attribute set values ​​for all business records in the business dataset of interest via the API provided by the blockchain; the key attribute set values ​​are stored as tuples in the list.

[0120] The list of key attribute values ​​for all business records can be obtained by directly accessing the storage system of business data from outside.

[0121] Alternatively, by deploying contracts that can retrieve business datasets in batches, it is possible to obtain a list of key attribute values ​​for all business records more efficiently via the blockchain.

[0122] S142, compare the verification voucher value list obtained from the constructed verification voucher value list with the key attribute set value list constructed in S141 to see if they are consistent;

[0123] If they are consistent, it is considered that there is no disaster in the business dataset, that is, the state of the blockchain system reflected by the business data in the business dataset is consistent with the state of the blockchain system reflected by the on-chain blocks.

[0124] If there is a discrepancy, the business data in the business dataset cannot accurately reflect the current state of the blockchain system, and there is disaster information in the business data, requiring disaster recovery operations to be performed.

[0125] As an optimization of the above embodiments, such as Figure 4As shown, for the case where the key attribute set values ​​of each business record in the business dataset are unique, i.e., the relationship between business records belongs to relation one, disaster recovery includes the following steps:

[0126] S211, Delete all business records from the business dataset whose key attribute set values ​​are in the key attribute value list but not in the verification voucher value list.

[0127] S212, reconstruct the business records whose key attribute set values ​​are in the verification certificate value list but not in the key attribute set value list constructed from all business records in the business dataset, and add the reconstructed business records to the business information table; the reconstruction of business records needs to be based on the valid transactions in the on-chain blocks.

[0128] Specifically, starting from the current block, the chain blocks are traversed in reverse order (i.e., the traversal process is performed from high to low block height) and the transaction list in the block is traversed in reverse order (i.e., the traversal starts from the last transaction in the transaction list packaged into the block and continues to the first transaction). The reverse traversal continues until the first valid transaction that meets the following conditions is found: (1) The operation type of the valid transaction is "add", and the value of the key attribute set of the currently added business record is in the "verification certificate value list" but not in the "key attribute set value list", (2) or the operation type of the valid transaction is "update", and the value of the key attribute set of the currently updated business record (distinguishing between the two cases of "no change" and "changed" key attribute set values, both based on the key attribute set value stored in the business information table of the updated record) is in the "verification certificate value list" but not in the "key attribute set value list".

[0129] When a valid transaction is "Add", the new business record in the input parameters of the transaction input information is obtained by parsing the function ABI of the contract function executing the business transaction, and the business record is inserted into the business information table. When a valid transaction is "Update", the changed business record in the input parameters of the transaction input information is also obtained by parsing the function ABI of the contract function, and the business record is inserted into the business information table.

[0130] Finally, add the key attribute set values ​​for newly added business records to the "Key Attribute Set Value List".

[0131] Regarding step S212 of the above technical solution, when the valid transaction operation type is "update," the business record obtained by reconstructing the latest valid transaction (i.e., "update") from the on-chain block is inserted into the business information table. Regarding the content of this business record (focusing on all attribute values), the above discussion mentioned directly parsing it from the input parameters of the contract function. In practical applications, for "update" operations, parsing the input parameters of the contract function usually cannot obtain the values ​​of all attributes (i.e., all fields of the record) in the business record. This is because, in the update operation of a business record, to improve the efficiency of transaction execution while ensuring the completion of the update task, the values ​​of attributes (fields) that have not been changed in the updated business record are usually not transmitted. Therefore, parsing the input parameters of the update business transaction can only obtain the latest value of the currently updated attribute (field), and cannot obtain the values ​​of other attributes of the business record. To obtain the values ​​of all attributes of the (updated) business record, the following technical solution needs to be implemented.

[0132] Starting from the block containing the retrieved "valid" transaction ("update" operation), the chain is traversed in reverse order, and the transactions within the block are also traversed in reverse order, tracing back all attribute (field) values ​​of the business record. The tracing process only focuses on whether the operation type of the valid transaction is "update" or "add". If the historical transaction is traced back to a "add" valid transaction, then the transaction will definitely reconstruct all the attribute values ​​of the business record that need to be obtained, and the transaction tracing can definitely be terminated. In the historical transaction tracing process, even if the reverse tracing does not reach a "add" valid transaction, all the attribute values ​​of the business record that needs to be reconstructed may still be obtained, and the transaction tracing can also be terminated at this point.

[0133] Effective historical transaction tracing requires using changes in the values ​​of key attribute sets as the tracing basis (i.e., the "update" operation may have updated the values ​​of key attribute sets). In this process, the values ​​of all attributes of the business record that have not been determined are determined. Once the values ​​of all attributes of the business record under observation are determined, the business record under observation is reconstructed. The reconstructed business record can be added to the business dataset to eliminate the data disaster of a key attribute set value appearing in the verification voucher value list but not in the key attribute set value list.

[0134] As an optimization of the above embodiments, for the second scenario, because the selected key attribute set values ​​cannot uniquely distinguish the business records in the business dataset, there are two or more business records with the same key attribute set values, or even two or more business records in the business dataset with completely identical attribute values. As mentioned earlier, such a business information table design is flawed and should be avoided. If the business content truly cannot select a key attribute set that uniquely distinguishes each business record, an additional auto-incrementing field that is prohibited from being null and has a unique value should be added as the primary key field of the information table. However, we still consider the case where the verified business dataset truly has no key attribute set values ​​that can uniquely distinguish the business records in the dataset, i.e., the second scenario. When such a scenario causes a data "disaster" due to an external "injection" operation, the technical solution for performing "disaster" elimination and data recovery is as follows.

[0135] For scenarios where the key attribute set of each business record in a business dataset cannot uniquely distinguish the business records in the dataset, i.e., the relationship between the business records belongs to relation two, such as... Figure 5 As shown, disaster recovery includes the following steps:

[0136] S221, When a key attribute set value exists in the key attribute set value list but does not exist in the verification voucher value list, perform an external operation to delete the business record with the key attribute set value of the specified value from the business dataset;

[0137] S222, when a certain key attribute set value appears more times in the key attribute set value list than the number of times that specific key attribute set value appears in the verification credential value list, assuming the key attribute set value is 'a', compare a list consisting of all business records in the business dataset with all such key attribute set values ​​'a' and another list consisting of all business records with key attribute set values ​​'a' resulting from the execution of historical transactions on the chain up to the current block; and delete all business records in the first list that are not in the second list from the business dataset.

[0138] Specifically: Traverse the blocks in reverse order from the current block, and traverse the transactions in the transaction list of each block in reverse order to construct business records with key attribute set value 'a'. During the reverse traversal construction process, when all attribute values ​​of all reconstructed business records have been determined and the number of constructed business records has reached n2, the reverse traversal stops, and the resulting n2 business records are the list list2 to be constructed.

[0139] Extract all business records from the business dataset whose key attribute set has a value of 'a'. The list of all these business records is called list1, and the number of records in this list must be n1.

[0140] Compare the two lists list1 and list2 constructed above, and identify the business records in list1 that do not appear in list2. The number of these identified business records should be n1-n2.

[0141] Remove the identified business records from list1 from the business dataset.

[0142] For each business record deleted from the business dataset, remove one key attribute set value 'a' from the "key attribute set value list".

[0143] S223, When there is a case where the value of the key attribute set exists in the value list of the verification certificate but does not exist in the value list of the key attribute set, start from the current block and traverse the on-chain blocks and the packaged transactions in reverse order to construct the business record of the specific key attribute set value. Traverse in reverse order until all attribute values ​​of the corresponding business record are determined, and add the reconstructed business record to the business dataset.

[0144] Specifically: Starting from the current block, traverse the blocks on the chain in reverse order, and then traverse each business transaction in the transaction list of each block in reverse order to construct business records with key attribute set value 'a'. During the reverse traversal construction process, when all attribute values ​​of all reconstructed business records have been determined and the number of constructed business records has reached n1, the reverse traversal stops, and the n1 business records obtained will be added to the business data table as follows.

[0145] The external operation adds (adds) the n1 business records with a value of 'a' for the key attribute set reconstructed based on on-chain blocks and transactions in the previous step to the business dataset. Note that this operation cannot be implemented through the blockchain's API or contract, otherwise it will corrupt the on-chain business transaction records again.

[0146] After adding a new business record, you also need to add the key attribute set value 'a' of the new business record to the "key attribute set value list". Note that each newly added business record needs to have its key attribute set value added to the "key attribute set value list" once, which means you need to operate the "key attribute set value list" to add a new unit n1 times.

[0147] S224, when a key attribute set value appears less often in the key attribute set value list than in the verification credential value list, compare a list consisting of all business records in the business dataset with all key attribute set values ​​of 'a' and another list consisting of all business records with key attribute set values ​​of 'a' resulting from the execution of historical on-chain transactions up to the current block; and add all business records in the second list that are not in the first list to the business dataset.

[0148] Specifically: Extract all business records with a key attribute set value of 'a' from the business dataset. The list consisting of all these business records is list1, and the number of records in this list is n1.

[0149] Traverse the blocks in reverse order from the current block, and then traverse the transactions in the transaction list of each block in reverse order to construct business records with key attribute set value 'a'. During the reverse traversal construction process, when all attribute values ​​of all business records to be reconstructed have been determined and the number of business records constructed has reached n2, the reverse traversal stops. The n2 business records obtained are the list list2 to be constructed.

[0150] Compare the two lists list1 and list2 constructed above, and identify the business records in list2 that do not appear in list1. The number of these identified business records should be n2-n1.

[0151] Insert the n2-n1 business records identified in list2 (i.e., those not in the business dataset associated with the business activity) into the business dataset.

[0152] For each business record inserted into the business dataset, add a key attribute set value 'a' to the "key attribute set value list".

[0153] As an optimization of the above embodiments, the method for global verification of business data includes the following steps:

[0154] S31, Define an empty business dataset instance;

[0155] S32, sequentially traverse all blocks on the chain from the starting block to the current block, sequentially traverse all transactions in the transaction list of each block, and execute valid business transactions one by one;

[0156] S33, based on the contract ABI and contract function ABI, parse the input information of the business transaction, parse the output information of the transaction receipt, obtain the input parameters and output parameters of the successfully executed business transaction, and then perform operations such as inserting, deleting, and updating attribute values ​​on the constructed business data instance in sequence.

[0157] S34, jump to step S32, and repeat until all blocks and all valid transactions have been traversed to obtain a business dataset instance that correctly reflects the current state of the blockchain system;

[0158] S35, using the business dataset instance constructed above, verify the business dataset that has been compromised due to external injection operations, and eliminate data errors.

[0159] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of this invention is defined by the appended claims and their equivalents.

Claims

1. A blockchain-oriented data disaster recovery method, characterized in that, Including the following steps: S10, Disaster Detection: This involves identifying discrepancies between the blockchain system state reflected in the business dataset and the blockchain system state reflected based on on-chain blocks to determine if a data disaster exists. First, all valid business transactions affecting the monitored business activities are screened from all transactions in all on-chain blocks, and a corresponding list of verification credential values ​​is constructed. Second, business data is accessed directly or via the blockchain API, and a list of key attribute values ​​is constructed accordingly. By comparing the list of verification credential values ​​and the list of key attribute values, the existence of disaster data in the business dataset is detected. include step: S11, Determine the detection indicators: The detection basis is determined to be each block on the blockchain and each transaction encapsulated in each block. The detection object is determined to be the business dataset of the industry application. The business dataset consists of each business record, and each business record is a set of all attribute values ​​representing the state of a business activity. For a certain business record that describes the occurrence or execution of a business activity, there are two relationships between it and other business records of the same business activity: Relationship 1: In the set of all these attributes, there exists one or more attributes that can uniquely identify the business record in the business dataset; Relationship 2: There is no one or more attributes that can distinguish each business record from other business records in the dataset. The attribute or combination of attributes selected to distinguish different business records is called the key attribute set; S12, Process business records that satisfy the aforementioned first type of relationship. The information table associated with the business activity has a set of key attributes that can uniquely distinguish each business record. Construct a list of verification voucher values ​​for relationship one for disaster verification. S13, Process business records that satisfy the aforementioned second type of relationship. If there is no key attribute set that can uniquely distinguish each business record in the business dataset, construct a list of verification credential values ​​for relationship two for disaster verification. S14, Disaster Verification: Based on the verification credential value list constructed above, examine the business dataset being verified. If the list of values ​​of the key attribute set of all business records in the business dataset is not equal to the verification credential value list, then a disaster exists in the business dataset. That is, before the last block that constructed the verification credential value list, the business dataset was injected with external operations, and the effects of all external injection operations did not cancel each other out, leaving a disaster in the dataset, causing the blockchain system state reflected by the business data in the business dataset to be inconsistent with the blockchain system state reflected by the on-chain blocks. S20, Disaster Recovery, eliminates or corrects disaster data based on the differences between the verification credential value list and the key attribute set value list, and by replaying the transactions in reverse order within the on-chain block; For cases where the key attribute set values ​​of each business record in the business dataset are unique, i.e., the relationship between business records belongs to relation one, disaster recovery includes the following steps: S211, Delete all business records from the business dataset whose key attribute set values ​​are in the key attribute value list but not in the verification voucher value list. S212, Reconstruct the business records whose key attribute set values ​​are in the verification certificate value list but not in the key attribute set value list constructed from all business records in the business dataset, and add the reconstructed business records to the business information table; the reconstruction of business records needs to be based on the valid transactions in the on-chain blocks. For scenarios where the key attribute set of each business record in a business dataset cannot uniquely distinguish the business records in the dataset, i.e., the relationship between the business records belongs to relation two, disaster recovery includes the following steps: S221, When a key attribute set value exists in the key attribute set value list but does not exist in the verification voucher value list, perform an external operation to delete the business record with the key attribute set value of the specified value from the business dataset; S222, when a certain key attribute set value appears more often in the key attribute set value list than in the verification credential value list, assuming the key attribute set value is 'a', compare a list consisting of all business records in the business dataset with all such key attribute set values ​​of 'a' and another list consisting of all business records with key attribute set values ​​of 'a' resulting from the execution of historical transactions on the chain up to the current block; and delete all business records in the first list that are not in the second list from the business dataset. S223, When there is a case where the value of the key attribute set exists in the value list of the verification certificate but does not exist in the value list of the key attribute set, start from the current block and traverse the on-chain blocks and the packaged transactions in reverse order to construct the business record of the specific key attribute set value. Traverse in reverse order until all attribute values ​​of the corresponding business record are determined, and add the reconstructed business record to the business dataset. S224, when a key attribute set value appears less often in the key attribute set value list than in the verification credential value list, compare a list consisting of all business records in the business dataset with all key attribute set values ​​of 'a' and another list consisting of all business records with key attribute set values ​​of 'a' resulting from the execution of historical on-chain transactions up to the current block; and add all business records in the second list that are not in the first list to the business dataset. S30, global verification of business data, sequential replay of transactions in on-chain blocks, construction of all business record instances created and updated by all business activities, verification of all business records in the business dataset; discovery of existing business data errors and the ability to eliminate discrepancies and restore the correct dataset; include step: S31, Define an empty business dataset instance; S32, sequentially traverse all blocks on the chain from the starting block to the current block, sequentially traverse all transactions in the transaction list of each block, and execute valid business transactions one by one; S33, based on the contract ABI and contract function ABI, parse the input information of the business transaction, parse the output information of the transaction receipt, obtain the input parameters and output parameters of the successfully executed business transaction, and then perform operations such as inserting, deleting, and updating attribute values ​​on the constructed business data instance in sequence. S34, jump to step S32, and repeat until all blocks and all valid transactions have been traversed to obtain a business dataset instance that correctly reflects the current state of the blockchain system; S35, Based on the business dataset instance constructed above, verify the business dataset that is in danger of disaster due to external injection operations, and eliminate data errors; Through disaster detection, disaster recovery, and global verification of business data, the state of the blockchain system reflected by the centralized business data is made consistent with the state of the blockchain system reflected by the on-chain blocks and the packaged business exchanges.

2. The blockchain-oriented data disaster recovery method according to claim 1, characterized in that, When determining the detection index in step S11, regardless of which of the two relationships mentioned above exists between business records, the detection index determined to be used to detect whether the state of the blockchain system reflected by the business data in the business dataset is consistent with the state of the blockchain system reflected by the on-chain blocks is: one attribute or a combination of multiple attributes that characterize the state of business activities. For the business records in the business dataset associated with the above business activities that satisfy the first type of relationship, the requirement is to find the smallest set of attribute combinations that can uniquely distinguish each business record; for the business records that have the second type of relationship, the solution is to select a suitable combination of multiple attributes based on the business details, and then group all business records according to the values ​​of the selected combination of multiple attributes. The attribute or combination of attributes selected to distinguish different business records is called the key attribute set. For the relationship between the first type of business records, a key attribute set is found, and all business records have different values ​​of the key attribute set. For the relationship between the second type of business records, a key attribute set is selected according to the business activity to effectively classify the records in the entire business dataset.

3. The blockchain-oriented data disaster recovery method according to claim 2, characterized in that, A single attribute or combination of attributes can be used to characterize the status of business activities. The primary key attribute of a business information table, which cannot be null, is one such attribute's detection metric.

4. A data disaster recovery method for blockchain according to claim 1, characterized in that, In step S12, business records that satisfy the aforementioned first type of relationship are processed. The information table associated with the business activity has a set of key attributes that can uniquely distinguish each business record. A list of verification credential values ​​for relationship one is constructed for disaster recovery verification, including the following steps: S121, Define an empty list of verification vouchers; S122, sequentially traverse all blocks on the chain, starting from the block with a block height of 1 and continuing up to the current block height. For each block, perform the following operation of traversing all transactions within the block. S123, Traverse all transactions in each block, that is, from the first transaction in the transaction list of the selected block to the last transaction in the transaction list, and perform the replay verification operation of the historical transactions below; S124, determine whether the current business transaction is the business activity that needs to be verified, that is, whether the transaction will modify the business records in the business information table associated with the business activity, involving adding, deleting or changing business records; if not, return to step S123 to perform the judgment of the next transaction; if yes, continue to perform the following steps. S125, Determine whether the current business transaction has been successfully executed. If so, change the constructed verification document value list according to the executed operation. If the current business transaction has not been successfully executed, keep the constructed verification document value list unchanged. S126, Return to step S123 and continue processing the next transaction in the current block; S127, return to step S122 and continue processing the next block on the chain until the specified block height or the latest block on the chain is reached.

5. A data disaster recovery method for blockchain according to claim 4, characterized in that, In step S124, business transactions that are not related to the currently verified business activity are excluded by verifying the to address of the transaction.

6. A data disaster recovery method for blockchain according to claim 1, characterized in that, In step S13, business records satisfying the aforementioned second type of relationship are processed. Since no key attribute set can uniquely distinguish each business record in the business dataset, a list of verification credential values ​​for relationship two is constructed for disaster verification, including the following steps: S131, Define an empty list of verification vouchers; S132, sequentially traverse all blocks on the chain, starting from the block with a block height of 1 and continuing up to the current block height. For each block, perform the following operation of traversing all transactions within the block. S133, Traverse all transactions in each block, that is, from the first transaction in the transaction list of the selected block to the last transaction in the transaction list, and perform the replay verification operation of the historical transactions below; S134, determine whether the current business transaction is the business activity that needs to be verified, that is, whether the transaction will modify the business records in the business information table associated with the business activity, involving adding, deleting or changing business records. If not, return to step S133 to perform the judgment of the next transaction. If yes, continue to perform the following steps. S135, determine whether the current business transaction was successfully executed. If not, do not adjust the constructed verification voucher value list; if the business transaction was successfully executed, then based on the number of business records affected by the business transaction in the function return value obtained from parsing the transaction receipt, perform the operation according to each business operation type: Obtain the transaction hash from the valid business transaction details obtained in step S134; obtain the transaction receipt of the current transaction based on the transaction hash; based on the contract function corresponding to the business transaction obtained in step S134, parse the output information in the transaction receipt obtained above using the ABI of the contract function, and determine whether the business transaction was successfully executed based on the parsing result; based on the return values ​​of other functions obtained from parsing the output information in the transaction receipt, obtain the number of business records affected by the operation executed by the business transaction; based on the parsing result of the business transaction input information parsing in step S134, and combined with the number of business records affected by the business transaction operation, adjust the composition of the verification voucher value list according to the operation category of the business transaction; Add a new operation: For the number of business records for each key attribute set whose values ​​are added, add the corresponding number of values ​​for that key attribute set to the verification voucher value list; Deletion operation: For the number of business records whose values ​​for each key attribute set have been deleted, remove the corresponding number of values ​​for that key attribute set from the constructed verification voucher value list; Update operation: For the number of business records whose old values ​​have been updated for each key attribute set, change the old value of the corresponding number of key attribute sets to the new value from the constructed verification voucher value list; S136, Return to step S133 and continue processing the next transaction in the current block; S137, return to step S132 and continue processing the next block on the chain until the specified block height or the latest block on the chain is reached.

7. A data disaster recovery method for blockchain according to claim 1, characterized in that, In step S14, the disaster verification includes the following steps: S141, obtain the list of key attribute set values ​​of all business records in the business dataset of interest via the API provided by the blockchain; The values ​​of the key attribute set are stored as tuples in the list; S142, compare the verification voucher value list obtained from the constructed verification voucher value list with the key attribute set value list constructed in S141 to see if they are consistent; If they are consistent, it is considered that there is no disaster in the business dataset, that is, the state of the blockchain system reflected by the business data in the business dataset is consistent with the state of the blockchain system reflected by the on-chain blocks. If there is a discrepancy, the business data in the business dataset cannot accurately reflect the current state of the blockchain system, and there is disaster information in the business data, requiring disaster recovery operations to be performed.

Images