CN116489168A - 一种面向区块链的数据灾难恢复方法 - Google Patents

Abstract

本发明公开一种面向区块链的数据灾难恢复方法，包括：灾难检测，发现业务数据集所反映的区块链系统状态与基于链上区块所反映的区块链系统状态的差异，确定是否存在数据灾难；灾难恢复：基于核验凭证取值列表和关键属性集取值列表的差异，并依据链上区块内交易重演来消除或更正灾难数据；甚至完成对业务数据集的全局核验；从而解决因外部主动的注入操作引起的业务数据集所反映的区块链系统状态与基于链上区块所刻画的区块链系统状态不一致的问题，即解决面向区块链的数据灾难恢复，消除因外部注入操作给产业应用业务数据集引入的灾难，使得基于业务数据集所反映的区块链系统状态与基于链上区块所刻画的区块链系统状态是一致的、相容的。

Description

一种面向区块链的数据灾难恢复方法

技术领域

本发明属于数据处理技术领域，特别是涉及一种面向区块链的数据灾难恢复方法。

背景技术

对于基于区块链的产业应用，因分离“区块链系统的链状态存储”与“产业应用业务数据的存储”(从管理和效率的角度分析，这是必要的和正确的处置方式)，并执行独立的状态、容错和例外管理。因外部操作可直接访问产业应用的业务数据，且没有破坏被操作存储系统所在节点的工作状态，即对于该节点至关重要的区块状态是健全的，与其他节点所维护的区块链状态是相容的，并不会破坏或影响区块链系统的正常运行，但因外部的“注入”的操作突破了链上业务交易需要被共识的限制，破坏了“业务数据集所反映的区块链系统状态”与“当前的区块链系统的真实状态”间的一致性，即产业应用的业务数据因外部的注入操作而引入“灾难”。

传统的处置数据管理和数据存储的容灾及灾备等措施或方案，对于保证存储系统所管理的业务数据的可用性、数据异常等是有效的，但是当需要处置的问题并不只是存储管理或使用问题时，而是在处置不同子系统的状态迁移、演进，以及不同子系统间的状态一致性等问题时，比如区块链的链上状态系统与区块链的业务数据系统之间，传统的处置措施和技术方案已不再适配当下被研究的问题了。

当前，对于因外部“注入”操作给产业应用的业务数据集引入的破坏行为，还没有被已有的研究很明确地指出或讨论，也没有明确的处置机制被提出或实践；分析出现当前情境的原因在于如下对区块链技术的认识：1)区块链的具有容错能力的共识机制，允许出现恶意节点或失效节点；2)分布式账本技术的加持，通过区块的分发，能够保证节点区块的一致性。

以上观点事实上也是对区块链技术的正确认识，只是在利用区块链技术实现产业应用时，还需要有相适配的机制或措施来解决区块链应用面临的新问题。其中以上提及的区块链固有的(或原生)的共识机制、分布式账本等可以被看作是“系统级”的机制，而解决区块链产业应用引起的新问题或挑战，则是需要引入“应用级”的机制。

区块链技术是支持去中心化和业务完备性的新兴计算模式，该技术的产业应用潜力被不断挖掘，在支持产业应用过程会面临新的需要解决的问题或挑战，比如本发明所针对的区块链在管理产业应用业务数据环节，在独立管理链上状态与业务数据状态的分离模式中，如何处置区块链链上状态和业务数据状态的一致性和相容性其实就是区块链技术产业应用需要解决但目前并没有解决的问题。

发明内容

为了解决上述问题，本发明提出了一种面向区块链的数据灾难恢复方法，解决因外部主动的注入操作引起的业务数据集所反映的区块链系统状态与区块链系统基于链上区块所刻画的区块链系统状态不一致的问题，即消除因外部注入操作给产业应用业务数据集引入的灾难，或解决基于区块链的数据灾难恢复，使得业务数据集所反映的区块链系统状态与基于链上区块所刻画的区块链系统状态是一致的、相容的。

为达到上述目的，本发明采用的技术方案是：一种面向区块链的数据灾难恢复方法，包括步骤：

S10,灾难检测，发现业务数据集所反映的区块链系统状态与基于链上区块所反映的区块链系统状态之间的差异，确定是否存在数据灾难；首先筛取链上全部区块的全部交易中影响被关注业务活动的全部有效业务交易，并对应构造出核验凭证取值列表；其次通过直接访问或经由区块链API访问业务数据，对应构造出关键属性集取值列表；通过对比核验凭证取值列表和关键属性集取值列表，发现业务数据集中灾难数据的存在；

S20,灾难恢复，基于核验凭证取值列表和关键属性集取值列表的差异，并依据链上区块内交易逆序重演来消除或更正灾难数据；

S30,业务数据的全局核验，顺序重演已上链区块内交易，构造全部业务活动所创建和更新的全部业务记录实例，核验业务数据集中的全部业务记录；发现存在的业务数据差错并能消除差异和恢复正确的数据集；

经灾难检测、灾难恢复及业务数据的全局核验，实现业务数据集中业务数据所反映的区块链系统状态与链上区块及被打包的业务交易所反映的区块链系统状态相一致。

进一步的是，所述灾难检测包括步骤：

S11,确定检测指标：确定检测依据是区块链上各个区块以及被封装入各区块的各个交易，确定检测对象是产业应用的业务数据集，业务数据集中由各业务记录构成，各业务记录是表征业务活动状态的全部属性取值的集合；则对于刻画业务活动发生或执行的某条业务记录，与同一业务活动的其他业务记录之间体现两种关系：关系一，在全部的这些属性构成的集合中，存在有一个属性或多个属性的组合来唯一标识业务数据集中的业务记录；关系二，是对于业务活动的业务记录并不存在一个属性或多个属性的组合来把各业务记录与数据集中其他的业务记录区别开来；被选择用于区分不同业务记录的一个属性或多个属性组合，称作关键属性集；

S12,处置满足前述第一类关系的业务记录，业务活动所关联的信息表存在能唯一区别各业务记录的关键属性集，构造关于关系一的核验凭证取值列表进行灾难核验；

S13,处置满足前述第二类关系的业务记录，不存在关键属性集能够唯一区别业务数据集中的各业务记录，构造关于关系二的核验凭证取值列表进行灾难核验；

S14,灾难核验：基于以上构造的核验凭证取值列表，审查被核验的业务数据集，若业务数据集中全部业务记录的关键属性集的取值构成的列表与核验凭证取值列表不相等，则业务数据集灾难存在，即截止至构造核验凭证取值列表的最后一个区块之前，业务数据集被注入外部操作，且全部外部注入操作引起的效果没有相互抵消，遗留下灾难于数据集，造成业务数据集中的业务数据所反映的区块链系统状态与链上区块所反映的区块链系统状态不一致。

进一步的是，在步骤S11中确定检测指标时，不论业务记录间存在的是上面两种关系中的哪种关系，被确定的用于检测业务数据集中的业务数据所反映的区块链系统状态是否与链上区块所反映的区块链系统状态一致的检测指标是：刻画业务活动状态的一个属性或多个属性的组合，如某业务信息表中不允许为空的主键属性就可以是一个属性的检测指标；

对于上面业务活动所关联的业务数据集的业务记录满足上面第一种关系，要求找到能唯一区别各条业务记录的属性组合的最小集；对于业务记录间存在的是第二种关系，则是根据业务详情选择一个合适的多个属性的组合，实现全部业务记录依所选多个属性的组合的取值进行分组；

被选择用于区分不同业务记录的一个属性或多个属性组合，即为关键属性集；对于第一类业务记录间的关系，找到一个关键属性集，所有业务记录都具有不同的关键属性集的取值；而对于第二类业务记录间的关系，依业务活动选择一个关键属性集，对全部业务数据集中的记录进行有效分类。

进一步的是，在所述步骤S12中，处置满足前述第一类关系的业务记录，业务活动所关联的信息表存在能唯一区别各业务记录的关键属性集，构造关于关系一的核验凭证取值列表进行灾难核验，包括步骤：

S121,定义核验凭证空列表；

S122,顺序遍历链上所有区块，自块高为1的区块开始，一直到当前块高为止，对于各个区块执行下面遍历区块内全部交易的操作；

S123,遍历各区块中的全部交易，即自被选定区块中交易列表的第一条交易开始一直到该交易列表的最后一条交易，执行下面历史交易的重演核验操作；

S124,判断当前业务交易是否是所要求核验的业务活动，即该交易是否会对业务活动所关联的业务信息表中的业务记录做出改动，涉及新增、删除或变更业务记录；如果不是，则返回步骤S123执行下一条交易的判断，如果是，则继续执行以下步骤；

S125,判断当前的业务交易是否被成功执行，若是，则根据被执行的操作对应变更被构造的核验凭证取值列表；如果当前的业务交易没有被成功执行，则维持被构造的核验凭证取值列表不变；

S126,返回第S123步，继续当前区块内下一个交易的处理；

S127,返回第S122步，继续链上下一个区块的处理，直至达到指定的块高或链上最新区块。

进一步的是，在所述步骤S124中，通过核验交易的to地址来排除与当前所核验业务活动无关的业务交易。

进一步的是，在所述步骤S13中，处置满足前述第二类关系的业务记录，不存在关键属性集能够唯一区别业务数据集中的各业务记录，构造关于关系二的核验凭证取值列表进行灾难核验，包括步骤：

S131,定义核验凭证空列表；

S132,顺序遍历链上所有区块，自块高为1的区块开始，一直到当前块高为止，对于各个区块执行下面遍历区块内全部交易的操作；

S133,遍历各区块中的全部交易，即自被选定区块中交易列表的第一条交易开始一直到该交易列表的最后一条交易，执行下面历史交易的重演核验操作；

S134,判断当前业务交易是否是所要求核验的业务活动，即该交易是否会对业务活动所关联的业务信息表中的业务记录做出改动，涉及新增、删除或变更业务记录，如果不是则返回步骤S133执行下一条交易的判断，如果是，则继续执行以下步骤；

S135,判断当前业务交易是否被成功执行，若否，则不调整被构造的核验凭证取值列表；若业务交易被成功执行，则需要依解析交易回执中得到的函数返回值中关于业务交易影响的业务记录条数，并对应各业务操作类型分别执行操作：

依S134步得到的有效业务交易详情中获取交易哈希；依交易哈希获取当前交易的交易回执；依S134步得到的业务交易所对应的合约函数，依该合约函数ABI解析上面得到的交易回执中的output信息，依解析结果判断业务交易是否执行成功；依解析交易回执中output信息得到的其他函数返回值，得到业务交易所执行的操作影响的业务记录条数；依S134解析业务交易input信息的解析结果，并结合业务交易操作影响的业务记录条数，依业务交易的操作类别对应调整核验凭证取值列表的构成；

新增操作：针对每一关键属性集的取值被添加的业务记录条数，添加对应个数该一个或多个属性组合的值到核验凭证取值列表；

删除操作：针对每一关键属性集的取值被删除的业务记录条数，从被构造的核验凭证取值列表中移除对应个数的该关键属性集的值；

更新操作：针对每一关键属性集的旧值被更新的业务记录条数，从被构造的核验凭证取值列表中变更对应个数的该关键属性集的旧值为新值；

S136,返回第S133步，继续当前区块内下一个交易的处理；

S137,返回第S132步，继续链上下一个区块的处理，直至达到指定的块高或链上最新区块。

进一步的是，在所述步骤S14中，灾难核验包括步骤：

S141，经由区块链提供的API获取所关注的业务数据集中全部业务记录的关键属性集取值列表；关键属性集取值在列表中以元组存在；

S142，比较所构造核验凭证取值列表中得到的核验凭证取值列表和S141中构造的关键属性集取值列表是否一致；

若一致，则认为业务数据集中无灾难存在，即业务数据集中的业务数据所反映的区块链系统状态与链上区块所反映的区块链系统状态相一致；

若不一致，则业务数据集中的业务数据不能正确反映区块链系统的当前状态，业务数据存在灾难信息，需要执行业务数据的灾难恢复操作。

进一步的是，对于处理业务数据集中各业务记录的关键属性集取值唯一的情况，即业务记录间关系属于关系一的情景，灾难恢复包括步骤：

S211,从业务数据集中删除关键属性集取值在关键属性值取值列表且又不在核验凭证取值列表中的全部业务记录；

S212,重构关键属性集取值在核验凭证取值列表中但又不在由业务数据集的全部业务记录构造得到的关键属性集取值列表中的业务记录，并将重构得到的业务记录添加入业务信息表；重构业务记录需要依链上区块中的有效交易来重构。

进一步的是，对于处理业务数据集中各业务记录的关键属性集并不能唯一区别业务数据集中的业务记录，即业务记录间关系属于关系二的情景，灾难恢复包括步骤：

S221,当某关键属性集取值存在于关键属性集取值列表但又不存在于核验凭证取值列表的情况，执行外部操作将关键属性集取值为指定值的业务记录从业务数据集中删除；

S222,当存在某关键属性集取值在关键属性集取值列表中出现的次数多于该特定的关键属性集取值在核验凭证取值列表中出现的次数，假定关键属性集取值为a，对比一个由业务数据集中所有这些关键属性集取值为a的全部业务记录构成的列表和另一个由链上历史交易执行到当前区块引起的关键属性集取值为a的全部业务记录构成的列表；并把第一个列表中所有不在第二个列表中的业务记录从业务数据集中全部删除；

S223,当存在关键属性集取值存在于核验凭证取值列表但又不存在于关键属性集取值列表的情况，从当前区块开始逆序遍历链上区块及被打包的交易，构建特定关键属性集取值的业务记录，逆序遍历至对应业务记录的全部属性取值被确定，并将重构的业务记录添加入业务数据集；

S224,当存在关键属性集取值在关键属性集取值列表中出现的次数少于该特定的关键属性集取值在核验凭证取值列表中出现的次数，对比一个由业务数据集中所有这些关键属性集取值为a的全部业务记录构成的列表和另一个由链上历史交易执行到当前区块引起的关键属性集取值为a的全部业务记录构成的列表；并把第二个列表中所有不在第一个列表中的业务记录新增到业务数据集。

进一步的是，所述业务数据的全局核验的方法包括步骤：

S31,定义一空的业务数据集实例；

S32,自起始区块顺序遍历链上全部区块直至当前区块、顺序遍历各区块交易列表中的全部交易，逐一执行有效的业务交易；

S33,依合约ABI、合约函数ABI，解析业务交易的input信息，解析交易回执的output信息，获取被成功执行的业务交易的输入参数、输出参数，依此对被构造的业务数据实例依次执行业务记录插入、删除、属性值更新等操作；

S34,跳转步骤S32，循环执行直至完成所有区块、所有有效交易的遍历，得到正确反映当前区块链系统状态的业务数据集实例；

S35，依以上构造的业务数据集实例来核验因外部注入操作引起的存在灾难的业务数据集，并消除数据差错。

采用本技术方案的有益效果：

本发明针对基于区块链的产业应用存在因外部注入操作造成业务数据集存在数据灾难问题，提出进行灾难检测、灾难恢复和业务数据全局核验的方案。本发明提出通过构造关键属性集以标识和区别业务记录，并做为数据灾难的检测指标。本发明提出基于关键属性集，把区块链的链上业务交易映射为核验凭证取值列表，即核验凭证取值列表的构成单元变化(如新增、移除单元)直接反映链上的业务交易(如新增业务记录、删除业务记录、变更业务记录)。本发明提出灾难检测的快速机制，即对比基于区块链链上业务交易构造得到的核验凭证取值列表和基于业务数据集构造的关键属性集取值列表两个列表中单元个数、取值的差异，快速定位数据集中的数据灾难。本发明提出灾难恢复的快速机制，即利用灾难检测发现的数据灾难，分别通过删除业务数据集中多余的业务记录，以及提出从当前区块开始逆序遍历区块及业务交易，重构业务数据集中缺失的业务记录,并执行发现即止(对业务交易为插入操作)和完整即止(对业务交易为更新操作)的交易回溯终止策略。本发明为保证本发明内容的完整，在技术方案的最后也给出了业务数据全局核验的方式。

本发明提出高效检测外部注入操作引起的数据灾难检测机制，即高效发现业务数据所反映的区块链系统状态与链上区块及交易所反映的区块链系统状态间的差异或矛盾。本发明高效解决因外部注入操作引起的数据灾难问题的技术方案，即数据灾难恢复，执行对产业应用业务数据集的增、删、改操作，消除业务数据所反映的区块链系统状态与链上区块及交易所反映的区块链系统状态间的差异或矛盾。本发明为服务对产业应用业务数据集完整性和可用性的全面审查，提出业务数据集的全局性核验方式。

附图说明

图1为本发明的一种面向区块链的数据灾难恢复方法流程示意图；

图2为本发明实施例中关系一情况下的灾难核验流程图；

图3为本发明实施例中关系二情况下的灾难核验流程图；

图4为本发明实施例中关系一情况下的灾难恢复流程图；

图5为本发明实施例中关系二情况下的灾难恢复流程图。

具体实施方式

为了使本发明的目的、技术方案和优点更加清楚，下面结合附图对本发明作进一步阐述。

把这些经过区块链系统提供的API接口所执行的外部操作，即注入操作，视为非授权的操作，细分这类操作可以将它们分为“被动”和“主动”的两个类型。其中，“被动”类型是指注入操作仅执行“读”操作，并不会破坏或影响由区块链维护的产业应用业务数据集中的业务信息，也不会造成“业务数据集所反映的区块链系统状态”与“区块链系统的真实状态”不一致；但是“主动”一类的注入操作，将会变更(新增、删除或更新等)产业应用业务数据集中的业务记录，引起“业务数据集所反映的区块链系统状态”(也是产业应用的系统状态，即产业应用系统各业务相关属性的取值即为其应用业务状态)与“区块链系统基于链上区块所刻画的区块链系统状态”不一致、不相容。

基于已上发现，本发明提出的技术方案将解决因外部“主动”的注入操作引起的“业务数据集所反映的区块链系统状态”与“基于链上区块所刻画的区块链系统状态”不一致的问题，即消除因外部“注入”操作给产业应用业务数据集引入的“灾难”，或解决基于区块链的“数据灾难”恢复，使得“业务数据集所反映的区块链系统状态”与“区块链基于链上区块所刻画的区块链系统状态”是一致的、相容的。

在本实施例中，参见图1所示，本发明提出了一种面向区块链的数据灾难恢复方法，包括步骤：

S10,灾难检测，发现业务数据集所反映的区块链系统状态与基于链上区块所反映的区块链系统状态之间的差异，确定是否存在数据灾难；首先筛取链上全部区块的全部交易中影响被关注业务活动的全部有效业务交易，并对应构造出核验凭证取值列表；其次通过直接访问或经由区块链API访问业务数据，对应构造出关键属性集取值列表；通过对比核验凭证取值列表和关键属性集取值列表，发现业务数据集中灾难数据的存在；

S20,业务数据的全局核验，顺序重演已上链区块内交易，构造全部业务活动所创建和更新的全部业务记录实例，核验业务数据集中的全部业务记录；发现存在的业务数据差错并能消除差异和恢复正确的数据集；

经灾难检测、灾难恢复及业务数据的全局核验，实现业务数据集中业务数据所反映的区块链系统状态与链上区块及被打包的业务交易所反映的区块链系统状态相一致。

作为上述实施例的优化方案，所述灾难检测包括步骤：

S11,确定检测指标：确定检测依据是区块链上各个区块以及被封装入各区块的各个交易，确定检测对象是产业应用的业务数据集，业务数据集由各业务记录构成，各业务记录是表征业务活动状态的全部属性取值的集合；则对于刻画业务活动发生或执行的某条业务记录，与同一业务活动的其他业务记录之间体现两种关系：关系一，在全部的这些属性构成的集合中，存在有一个属性或多个属性的组合来唯一标识业务数据集中的业务记录，比如在数据表设计中取值具有“unique”要求的“primarykey”(主键字段)的定义，即能起到唯一区别各业务记录的能力；关系二，是对于业务活动的业务记录并不存在一个属性或多个属性的组合来把各业务记录与数据集中其他的业务记录区别开来，比如某业务数据集中存在某条业务记录，该业务记录的各个属性的取值在业务数据集中都存在一条(或多条)业务记录就被关注的对应属性取值相同；被选择用于区分不同业务记录的一个属性或多个属性组合，称作关键属性集；

处置上面二类的业务记录关系，选择一个属性或多个属性的组合，结合后面提出的历史交易的重演核验方法，能够完成对业务数据集所反映的区块链系统状态与基于链上区块所反映的区块链系统状态是否一致进行评判的任务，且当存在业务数据灾难情况下，执行历史交易的重演恢复方法可以重构正确反映当前区块链系统状态的正确业务数据集。

业务活动所关联的业务信息表中的全部业务记录反映的是经由区块链上部署的合约执行的业务操作以及外部主动的注入操作的累积结果，则该业务信息表中的全部业务记录仅有被检测的对象；从链上的全部区块来构造核验当前业务信息表中的业务记录是否正确反映当前区块链系统真实状态的核验凭证，即由链上的全部区块来构造前一步骤所选择的关键属性集取值演进至当前区块的取值列表，称该列表为核验凭证取值列表，列表中关键属性集的取值以元组形式存在；需要注意的是：这里“核验凭证取值列表”所用的“列表”是指数据单元组织意义上的概念，即允许出现重复单元(值)，不采用“集合”，是因为后者不支持重复单元；允许出现重复单元对于支持业务信息表中业务记录间关系为前述第二类关系的业务活动至关重要。

S12,处置满足前述第一类关系的业务记录，业务活动所关联的信息表存在能唯一区别各业务记录的关键属性集，构造关于关系一的核验凭证取值列表进行灾难核验；

S13,处置满足前述第二类关系的业务记录，不存在关键属性集能够唯一区别业务数据集中的各业务记录，构造关于关系二的核验凭证取值列表进行灾难核验；

S14,灾难核验：基于以上构造的核验凭证取值列表，审查被核验的业务数据集，若业务数据集中全部业务记录的关键属性集的取值构成的列表与核验凭证取值列表不相等，则业务数据集灾难存在，即截止至构造核验凭证取值列表的最后一个区块之前，业务数据集被注入外部操作，且全部外部注入操作引起的效果没有相互抵消，遗留下灾难于数据集，造成业务数据集中的业务数据所反映的区块链系统状态与链上区块所反映的区块链系统状态不一致。

优选的，在步骤S11中确定检测指标时，不论业务记录间存在的是上面两种关系中的哪种关系，被确定的用于检测业务数据集中的业务数据所反映的区块链系统状态是否与链上区块所反映的区块链系统状态一致的检测指标是：刻画业务活动状态的一个属性或多个属性的组合，如某业务信息表中不允许为空的主键属性就可以是一个属性的检测指标；

对于上面业务活动所关联的业务数据集的业务记录满足上面第一种关系，要求找到能唯一区别各条业务记录的属性组合的最小集(如果能仅利用“一个属性”即可唯一区分为最优)；对于业务记录间存在的是第二种关系，则是根据业务详情选择一个合适的多个属性的组合，能够实现全部业务记录依所选多个属性的组合的取值进行分组；当然选择业务记录的全部属性的组合是能最大限度地区分业务活动所关联业务数据表中的各业务记录，但是实际实践中需要综合考虑属性组合选择的有效性和检测业务数据是否存在灾难的计算效率，来选择一个有效的多个属性组合；

被选择用于区分不同业务记录的一个属性或多个属性组合，即关键属性集；对于第一类业务记录间的关系，找到一个关键属性集，所有业务记录都具有不同的关键属性集的取值；而对于第二类业务记录间的关系，依业务活动选择一个关键属性集，对全部业务数据集中的记录进行有效分类。

优选的，如图2所示，在所述步骤S12中，处置满足前述第一类关系的业务记录，业务活动所关联的信息表存在能唯一区别各业务记录的关键属性集，构造关于关系一的核验凭证取值列表进行灾难核验，包括步骤：

S121,定义核验凭证空列表，记为verify_credential_value_list，即初始化为空“[]”；

S122,遍历链上所有区块，自块高为1的区块开始，一直到当前块高为止，对于各个区块执行下面遍历区块内全部交易的操作；

S123,顺序遍历各区块中的全部交易，即自被选定区块中交易列表的第一条交易开始一直到该交易列表的最后一条交易，执行下面历史交易的重演核验操作；

S124,判断当前业务交易是否是所要求核验的业务活动，即该交易是否会对业务活动所关联的业务信息表中的业务记录做出改动，涉及新增、删除或变更业务记录，如果不是则返回步骤S123执行下一条交易的判断，如果是，则继续执行以下步骤。

S125,判断当前的业务交易是否被成功执行，若是，则根据被执行的操作(即触发调用合约函数的业务交易)对应变更被构造的核验凭证取值列表；如果当前的业务交易没有被成功执行，则维持被构造的核验凭证取值列表不变；

S126,返回第S123步，继续当前区块内下一个交易的处理；

S127,返回第S122步，继续链上下一个区块的处理，直至达到指定的块高或链上最新区块。

对于以上技术方案中的步骤S125，需要理解“交易执行成功”的含义，即交易的执行过程没有发生或存在系统或平台一级的异常或错误；但是从Client触发合约(调用合约函数)的动机(或目的)来分析，如果本次交易的结果是动作预期引起的结果，比如合约调用的是“新增”业务记录，且交易执行的结果也是在业务信息表中添加了一条业务记录，则该交易就是“执行成功的交易”；而如果交易执行的结果因为某种原因并没有把相关业务记录插入到业务信息表，则该交易就是“执行失败的交易”，交易执行失败的相关原因如标识欲被新增的业务记录的“关键属性集”的取值已在业务信息表中的某条记录中出现，因要求能唯一标识业务记录的属性(一个或多个属性的组合，即关键属性集)取值是唯一的，则记录不能被新增。对于执行成功的交易，核验凭证的构造依不同的操作对应变更“核验凭证取值列表”的单元构成，核验凭证取值列表构造执行如下方案：

“新增”业务记录：则添加当前被新增业务记录的“关键属性集”(看作元组)的取值到凭证列表verify_credential_value_list中去。从如何记录“新增”这个动作的角度来理解，向“核验凭证取值列表”列表中添加一个值(被新增业务记录的“关键属性集”取值)可以唯一对应“新增”业务记录的这个操作。

“删除”业务记录：则从凭证列表中移除当前被移除业务记录的“关键属性集”的取值。同理，从“核验凭证取值列表”中移除一个“关键属性集”的某个取值，也唯一对应着当下的“删除”业务记录的这个操作。

“更新”业务记录：则先判断是否是更新了业务记录的这个“关键属性集”的取值，若是，则相应变更凭证列表中对应的旧值为新值；若不是，则无需变更凭证列表的单元构成或单元的取值。因为“变更”操作既可能变更被选定的“关键属性集”的取值，也可能变更业务记录中其他属性的取值，若要借助向“核验凭证取值列表”中插入某个数值以对应(刻画)当下的“更新”操作，通过插入被本次“更新”操作所更改的全部属性的取值是一个可行的值，但是这样的处理机制，就需要选择业务记录的全部属性来构成“关键属性集”，即做为检测外部“注入”操作的检测指标，这样的处置机制难以核查外部“注入”操作(因为需要完成对全部历史交易的重演)，难以高效发现数据“灾难”。所以，对于“更新”业务操作(业务交易)，下面的“灾难”检测、“灾难”恢复等的机制和方案都仅关注“关键属性集”被“更新”的操作。

在所述步骤S124中，通过核验交易的to地址(即所部署的智能合约地址，该地址唯一确定某合约)来排除与当前所核验业务活动(关联业务信息表)无关的业务交易。

需要注意被打包入区块的业务交易，既可能是调用了系统合约(即区块链平台的预设合约，无需用户部署即可触发调用)，也可能是调用用户部署的合约，来执行相关的业务活动，所以不要漏掉任何可变更业务信息表中业务记录的任何类型的合约(系统合约或用户合约)被调用引起的业务交易，即合法的“to”地址通常不会只有一个，通常会有多个，即不要漏掉任何的用户合约，也不要漏掉任何的系统合约。

需要注意在产业应用的运行过程，存在业务合约的升级操作(不同版本的被部署合约执行的业务活动关联相同的业务信息数据表)，同名合约的多次部署(如版本升级)，各版本将对应不同的合约地址；所以在构造核验凭证取值列表时，也不要漏掉任何版本的业务合约引起的业务活动，即合法的“to”地址列表中应包括全部版本的被部署合约的合约地址。

需要注意被打包入链区块的交易都是需要共识(且经过共识)的变更区块链系统状态的交易，是不会包含对业务信息表的如查询或检索操作的不需要共识的业务交易的；所以所有对以上合法“to”地址(合约地址)的合约调用，一定是改变了业务活动所关联业务数据信息表中业务记录的业务操作，当然也改变了区块链系统的状态。

一些例外的情况需要考虑，即是那些交易失败的交易也会被记录(更准确地讲应该是“错误”的交易)，即被打包入区块，交易失败的原因可以有多种，比如gas不足、业务逻辑错误(如访问了链上不存在的对象)等等；那么对于这些交易，因交易并没有真正发生(交易执行的结果没有上链或被执行的部分交易被回滚，所有区块链系统的状态并没有发生变化)，在构造核验凭证取值列表时，就需要排除这些失败的交易。

优选的，在所述步骤S13中，如图3所示，处置满足前述第二类关系的业务记录，不存在关键属性集能够唯一区别业务数据集中的各业务记录，构造关于关系二的核验凭证取值列表进行灾难核验，包括步骤：

S131,定义核验凭证空列表，记为verify_credential_value_list，即初始化为空“[]”；

S132,顺序遍历链上所有区块，自块高为1的区块开始，一直到当前块高为止，对于各个区块执行下面遍历区块内全部交易的操作；

S133,遍历各区块中的全部交易，即自被选定区块中交易列表的第一条交易开始一直到该交易列表的最后一条交易，执行下面历史交易的重演核验操作；

S134,判断当前业务交易是否是所要求核验的业务活动，即该交易是否会对业务活动所关联的业务信息表中的业务记录做出改动，涉及新增、删除或变更业务记录，如果不是则返回步骤S133执行下一条交易的判断，如果是，则继续执行以下步骤。

S135,判断当前业务交易是否被成功执行，若否(即本次的合约调用，因相关原因并没有执行对业务数据集的变更操作)，则不调整被构造的核验凭证取值列表；若业务交易被成功执行，则需要依解析交易回执中得到的函数返回值中关于业务交易(新增、删除、变更等)影响的业务记录条数，并对应各业务操作类型分别执行操作：

依S134步得到的有效业务交易详情中获取交易哈希；依交易哈希获取当前交易的交易回执；依S134步得到的业务交易所对应的合约函数，依该合约函数ABI解析上面得到的交易回执中的output信息，依解析结果判断业务交易是否执行成功；依解析交易回执中output信息得到的其他函数返回值，得到业务交易所执行的操作影响的业务记录条数；依S134解析业务交易input信息的解析结果，并结合业务交易操作影响的业务记录条数，依业务交易的操作类别对应调整核验凭证取值列表的构成；

新增操作：针对关键属性集的取值被添加的业务记录条数，添加对应个数该一个或多个属性组合的值到核验凭证取值列表；

删除操作：针对关键属性集的取值被删除的业务记录条数，从被构造的核验凭证取值列表中移除对应个数的该关键属性集的值；

更新操作：针对关键属性集的旧值被更新的业务记录条数，从被构造的核验凭证取值列表中变更对应个数的该关键属性集的旧值为新值；

S136,返回第S133步，继续当前区块内下一个交易的处理；

S137,返回第S132步，继续链上下一个区块的处理，直至达到指定的块高或链上最新区块。

适用于“第二类情景”—即并不存在“关键属性集”(“一个属性”或“多个属性的组合”)能够唯一区别业务数据集中的各业务记录的情况，但前面已经提到依据业务活动详情选择的有效“关键属性集”，它的取值能够对业务数据集中的全部业务记录进行有效分组(分类)。区别于第一类情景，在业务数据集中各业务记录被考察的“关键属性集”的取值唯一，故能唯一区别各业务记录，则依链上区块所打包的交易构造得到的核验凭证取值列表中的各单元一定也是取值各异。但是对于第二类情景，被关注的“关键属性集”(多个属性的组合)并不能唯一区别业务数据集中的业务记录，即允许存在两条或多条业务记录就被关注的“关键属性集”取值相同，相应对于该情景在依链上被打包入区块的交易构造得到的核验凭证取值列表中也应存在两个或多个取值相同的核验凭证，即“关键属性集”的取值允许重复多次出现。

因为以上区别，在为第一类情景构造核验凭证取值列表的步骤S125，该步仅依赖“合约交易是否被成功执行”这一判断(依解析得到的交易回执信息)，并结合合约交易执行的函数类型(新增、删除或更新)，即可利用解析得到的合约函数输入参数对应构造核验凭证取值列表。但是对于第二类情景，“合约交易是否被成功执行”只是“是否需要调整”核验凭证取值列表的判断条件(成功则需要调整、不成功则不需要调整)，但是“如何调整”核验凭证取值列表还需要进一步利用解析得到的交易回执中的进一步信息，即函数返回值中关于被新增的业务记录条数、被删除的业务记录的条数、被更新的业务记录的条数信息，来调整核验凭证取值列表。

对于上述方案第S135步，对于“新增”业务记录操作，通常都只是新增一条记录，除非执行的是批量导入操作，即批量新增操作；对于第一类情景，对于批量导入操作，被批量新增的业务记录也是各自具有唯一的“关键属性集”取值，但是对于第二类情景，可以有多条批量新增的业务记录“关键属性集”的取值相同，已在第S135步中提到需要在被构造的核验凭证取值列表中添加对应数量的“关键属性集”的取值，虽然这些被添加的值是相同的。对于“删除”业务记录操作，在业务数据集中满足约束条件的记录可能是多条，就假定以某个具体的“关键属性集”的取值为检索条件，满足该检索条件的业务记录可能就会有多条，则需要把被移除的这些业务记录的“关键属性集”的值从被构造的核验凭证取值列表中逐记录移除该记录的“关键属性集”的值，即需要保证从业务数据集中移除的记录条数和从核验凭证取值列表中被移除的某“关键属性集”取值的个数相等。

优选的，在所述步骤S14中，灾难核验包括步骤：

S141，经由区块链提供的API获取所关注的业务数据集中全部业务记录的关键属性集取值列表；关键属性集取值在列表中以元组存在；

可以通过外部直接访问业务数据的存储系统获取全部业务记录的关键属性值取值列表。

亦可以通过部署可批量检索业务数据集的合约，实现更高效地经由区块链获取全部业务记录的关键属性集取值列表。

S142，比较所构造核验凭证取值列表中得到的核验凭证取值列表和S141中构造的关键属性集取值列表是否一致；

若一致，则认为业务数据集中无灾难存在，即业务数据集中的业务数据所反映的区块链系统状态与链上区块所反映的区块链系统状态相一致；

若不一致，则业务数据集中的业务数据不能正确反映区块链系统的当前状态，业务数据存在灾难信息，需要执行业务数据的灾难恢复操作。

作为上述实施例的优化方案，如图4所示，对于处理业务数据集中各业务记录的关键属性集取值唯一的情况，即业务记录间关系属于关系一的情景，灾难恢复包括步骤：

S211,从业务数据集中删除关键属性集取值在关键属性值取值列表且又不在核验凭证取值列表中的全部业务记录；

S212,重构关键属性集取值在核验凭证取值列表中但又不在由业务数据集的全部业务记录构造得到的关键属性集取值列表中的业务记录，并将重构得到的业务记录添加入业务信息表；重构业务记录需要依链上区块中的有效交易来重构。

具体的，自当前区块起逆序遍历链上区块(即遍历过程区块高度由高到低执行)并逆序遍历区块中的交易列表(即遍历由被打包入区块中交易列表的最后一个交易开始一直到第一个交易)，逆序遍历直到首次找到如下满足条件的有效交易，(1)有效交易的操作类型为“新增”，且当前被新增业务记录的关键属性集的值在“核验凭证取值列表”但不在“关键属性集取值列表”，(2)或者有效交易的操作类型为“更新”，且当前被更新业务记录的关键属性集取值(区别更新操作“没有改变”和“改变了”关键属性集的取值两种情况，都以被更新记录存入业务信息表的关键属性集取值为准)在“核验凭证取值列表”但不在“关键属性集取值列表”。

有效交易为“新增”时，依执行业务交易的合约函数的函数ABI解析得到交易输入“input”信息中输入参数中的新增业务记录，并将该业务记录插入到业务信息表中。有效交易为“更新”时，也是依合约函数ABI解析得到交易输入“input”信息中输入参数中的被变更业务记录，并将该业务记录插入到业务信息表中。

最后，添加新增业务记录的关键属性集取值到“关键属性集取值列表”。

关于以上技术方案第S212步中当有效交易操作类型为“更新”时，把重构自链上区块最新有效交易(即“更新”)得到的业务记录插入到业务信息表，关于该业务记录(应关注业务记录的全部属性取值)的内容，上面论述提到直接解析自合约函数的输入参数；在现实应用中，对于“更新”操作，解析合约函数的输入参数通常是不能得到业务记录中全部属性(即记录的全部字段)的取值的。因为，业务记录的更新操作中，在保证完成更新任务的目标下，为了提高交易执行的效率，通常并不传输被更新业务记录没有被变更属性(字段)的取值，则解析更新业务交易的输入参数，仅能得到当前被更新属性(字段)的最新取值，而不能得到该业务记录其他属性的取值，为了得到(被更新)业务记录的全部属性的取值，需要执行如下技术方案。

从被检索到的“有效”交易(“更新”操作)所在的区块开始，逆序遍历链上区块并逆序遍历区块中的交易，追溯该业务记录的全部属性(字段)取值；追溯过程仅关注有效交易的操作类型为“更新”或“新增”，如果追溯历史交易到某“新增”有效交易，则至此交易一定重构出需要得到的业务记录的全部属性取值，即一定可以终止交易追溯；在历史交易追溯过程，即使没有逆序追溯到达某“新增”有效交易，需要被重构的业务记录的所有属性取值也可能被全部得到，至此也可以终止交易追溯。

有效历史交易追溯需要以关键属性集的取值的变迁为追溯依据(即“更新”操作可能更新了关键属性集的取值)，并在此过程确定所有该业务记录未被确定的属性的取值，当完成被关注业务记录的所有属性的取值后，则完成被关注业务记录的重构，可以把重构得到的业务记录新增入业务数据集，消除某关键属性集的取值出现在核验凭证取值列表中但不在关键属性集取值列表中的数据灾难。

作为上述实施例的优化方案，对于第二类情景，因为所选择的关键属性集取值并不能唯一区别业务数据集中的业务记录，存在两条或多条业务记录具有相同的关键属性集取值，甚至在业务数据集中存在全部属性取值完全相同的两条或多条业务记录；在前面已经提到这样的业务信息表设计是有瑕疵的，应避免出现这样的业务信息表设计，若业务内容的确无法选择能唯一区别各业务记录的关键属性集，则应额外新增禁止为空且取值唯一的自增字段来做为信息表的主键字段。但是，这里仍然考虑如果被核验的业务数据集的确没有关键属性集的取值能唯一区别数据集中的业务记录的情况，即第二类情景；当此类情景因外部“注入”操作引起数据“灾难”，执行“灾难”消除和恢复数据的技术方案如下。

对于处理业务数据集中各业务记录的关键属性集并不能唯一区别业务数据集中的业务记录，即业务记录间关系属于关系二的情景，如图5所示，灾难恢复包括步骤：

S221,当某关键属性集取值存在于关键属性集取值列表但又不存在于核验凭证取值列表的情况，执行外部操作将关键属性集取值为指定值的业务记录从业务数据集中删除；

S222,当存在某关键属性集取值在关键属性集取值列表中出现的次数(多于该特定的关键属性集取值在核验凭证取值列表中出现的次数，假定关键属性集取值为a，对比一个由业务数据集中所有这些关键属性集取值为a的全部业务记录构成的列表和另一个由链上历史交易执行到当前区块引起的关键属性集取值为a的全部业务记录构成的列表；并把第一个列表中所有不在第二个列表中的业务记录从业务数据集中全部删除；

具体的：从当前区块逆序遍历区块，并逆序遍历各区块交易列表中的交易，构造得到关键属性集取值为a的业务记录，在逆序遍历构造过程当满足被重构的全部业务记录的全部属性取值已确定，且构造得到的业务记录条数已达n2时，逆序遍历停止，得到的n2条业务记录即为需要被构造的列表list2。

从业务数据集中提取关键属性集取值为a的全部业务记录，这些全部业务记录构成的列表即为list1，且该列表的记录条数一定为n1。

比较以上构造得到的两个列表list1和list2，标识出list1中不在list2中出现的业务记录，这些被标识的业务记录数量应该为n1-n2。

从业务数据集中删除list1中那些被标识的业务记录。

对应每条被从业务数据集中删除的业务记录，从“关键属性集取值列表”中对应移除一个关键属性集取值a。

S223,当存在关键属性集取值存在于核验凭证取值列表但又不存在于关键属性集取值列表的情况，从当前区块开始逆序遍历链上区块及被打包的交易，构建特定关键属性集取值的业务记录，逆序遍历至对应业务记录的全部属性取值被确定，并将重构的业务记录添加入业务数据集；

具体的：从当前区块开始逆序遍历链上区块，并逆序遍历各区块交易列表中的各业务交易，构造得到关键属性集取值为a的业务记录，在逆序遍历构造过程当满足被重构的全部业务记录的全部属性取值已确定，且构造得到的业务记录条数已达n1时，逆序遍历停止，得到的n1条业务记录将执行如下操作添加入业务数据表。

执行外部操作将上一步依链上区块和交易重构的关键属性集取值为a的n1条业务记录添加(新增)到业务数据集中。注意本步操作不能通过区块链提供的API或合约来实现，否则会再次破坏链上业务交易记录。

在完成业务记录新增后，也需要把新增业务记录的关键属性集取值a添加到“关键属性集取值列表”，注意每条被新增的业务记录都需要对应地添加一次关键属性集取值到“关键属性集取值列表”，即需要操作“关键属性集取值列表”以新增单元n1次。

S224,当存在关键属性集取值在关键属性集取值列表中出现的次数少于该特定的关键属性集取值在核验凭证取值列表中出现的次数，对比一个由业务数据集中所有这些关键属性集取值为a的全部业务记录构成的列表和另一个由链上历史交易执行到当前区块引起的关键属性集取值为a的全部业务记录构成的列表；并把第二个列表中所有不在第一个列表中的业务记录新增到业务数据集。

具体的：从业务数据集中提取关键属性集取值为a的全部业务记录，这些全部业务记录构成的列表即为list1，且该列表的记录条数为n1。

从当前区块逆序遍历区块，并逆序遍历各区块交易列表中的交易，构造得到关键属性集取值为a的业务记录，在逆序遍历构造过程当满足被重构的全部业务记录的全部属性取值已确定，且构造得到的业务记录条数已达n2时，逆序遍历停止，得到的n2条业务记录即为需要被构造的列表list2。

比较以上构造得到的两个列表list1和list2，标识出list2中不在list1中出现的业务记录，这些被标识的业务记录数量应该为n2-n1。

将list2中被标识的n2-n1条业务记录(即不在业务活动所关联的业务数据集中)插入到业务数据集。

对应每条被插入到业务数据集中的业务记录，新增一个关键属性集取值a到“关键属性集取值列表”。

作为上述实施例的优化方案：所述业务数据的全局核验的方法包括步骤：

S31,定义一空的业务数据集实例；

S32,自起始区块顺序遍历链上全部区块直至当前区块、顺序遍历各区块交易列表中的全部交易，逐一执行有效的业务交易；

S33,依合约ABI、合约函数ABI，解析业务交易的input信息，解析交易回执的output信息，获取被成功执行的业务交易的输入参数、输出参数，依此对被构造的业务数据实例依次执行业务记录插入、删除、属性值更新等操作；

S34,跳转步骤S32，循环执行直至完成所有区块、所有有效交易的遍历，得到正确反映当前区块链系统状态的业务数据集实例；

S35，依以上构造的业务数据集实例来核验因外部注入操作引起的存在灾难的业务数据集，并消除数据差错。

以上显示和描述了本发明的基本原理和主要特征和本发明的优点。本行业的技术人员应该了解，本发明不受上述实施例的限制，上述实施例和说明书中描述的只是说明本发明的原理，在不脱离本发明精神和范围的前提下，本发明还会有各种变化和改进，这些变化和改进都落入要求保护的本发明范围内。本发明要求保护范围由所附的权利要求书及其等效物界定。

Claims (10)

1.一种面向区块链的数据灾难恢复方法，其特征在于，包括步骤：

S10,灾难检测，发现业务数据集所反映的区块链系统状态与基于链上区块所反映的区块链系统状态之间的差异，确定是否存在数据灾难；首先筛取链上全部区块的全部交易中影响被关注业务活动的全部有效业务交易，并对应构造出核验凭证取值列表；其次通过直接访问或经由区块链API访问业务数据，对应构造出关键属性集取值列表；通过对比核验凭证取值列表和关键属性集取值列表，发现业务数据集中灾难数据的存在；

S20,灾难恢复，基于核验凭证取值列表和关键属性集取值列表的差异，并依据链上区块内交易逆序重演来消除或更正灾难数据；

S30,业务数据的全局核验，顺序重演已上链区块内交易，构造全部业务活动所创建和更新的全部业务记录实例，核验业务数据集中的全部业务记录；发现存在的业务数据差错并能消除差异和恢复正确的数据集；

经灾难检测、灾难恢复及业务数据的全局核验，实现业务数据集中业务数据所反映的区块链系统状态与链上区块及被打包的业务交易所反映的区块链系统状态相一致。

2.根据权利要求1所述的一种面向区块链的数据灾难恢复方法，其特征在于，所述灾难检测包括步骤：

S11,确定检测指标：确定检测依据是区块链上各个区块以及被封装入各区块的各个交易，确定检测对象是产业应用的业务数据集，业务数据集由各业务记录构成，各业务记录是表征业务活动状态的全部属性取值的集合；则对于刻画业务活动发生或执行的某条业务记录，与同一业务活动的其他业务记录之间体现两种关系：关系一，在全部的这些属性构成的集合中，存在有一个属性或多个属性的组合来唯一标识业务数据集中的业务记录；关系二，业务活动的业务记录并不存在一个属性或多个属性的组合来把各业务记录与数据集中其他的业务记录区别开来；被选择用于区分不同业务记录的一个属性或多个属性组合，称作关键属性集；

S12,处置满足前述第一类关系的业务记录，业务活动所关联的信息表存在能唯一区别各业务记录的关键属性集，构造关于关系一的核验凭证取值列表进行灾难核验；

S13,处置满足前述第二类关系的业务记录，不存在关键属性集能够唯一区别业务数据集中的各业务记录，构造关于关系二的核验凭证取值列表进行灾难核验；

S14,灾难核验：基于以上构造的核验凭证取值列表，审查被核验的业务数据集，若业务数据集中全部业务记录的关键属性集的取值构成的列表与核验凭证取值列表不相等，则业务数据集灾难存在，即截止至构造核验凭证取值列表的最后一个区块之前，业务数据集被注入外部操作，且全部外部注入操作引起的效果没有相互抵消，遗留下灾难于数据集，造成业务数据集中的业务数据所反映的区块链系统状态与链上区块所反映的区块链系统状态不一致。

3.根据权利要求2所述的一种面向区块链的数据灾难恢复方法，其特征在于，在步骤S11中确定检测指标时，不论业务记录间存在的是上面两种关系中的哪种关系，被确定的用于检测业务数据集中的业务数据所反映的区块链系统状态是否与链上区块所反映的区块链系统状态一致的检测指标是：刻画业务活动状态的一个属性或多个属性的组合，如某业务信息表中不允许为空的主键属性就可以是一个属性的检测指标；

对于上面业务活动所关联的业务数据集的业务记录满足上面第一种关系，要求找到能唯一区别各条业务记录的属性组合的最小集；对于业务记录间存在的是第二种关系，则是根据业务详情选择一个合适的多个属性的组合，实现全部业务记录依所选多个属性的组合的取值进行分组；

被选择用于区分不同业务记录的一个属性或多个属性组合，即为关键属性集；对于第一类业务记录间的关系，找到一个关键属性集，所有业务记录都具有不同的关键属性集的取值；而对于第二类业务记录间的关系，依业务活动选择一个关键属性集，对全部业务数据集中的记录进行有效分类。

4.根据权利要求2所述的一种面向区块链的数据灾难恢复方法，其特征在于，在所述步骤S12中，处置满足前述第一类关系的业务记录，业务活动所关联的信息表存在能唯一区别各业务记录的关键属性集，构造关于关系一的核验凭证取值列表进行灾难核验，包括步骤：

S121,定义核验凭证空列表；

S122,顺序遍历链上所有区块，自块高为1的区块开始，一直到当前块高为止，对于各个区块执行下面遍历区块内全部交易的操作；

S123,遍历各区块中的全部交易，即自被选定区块中交易列表的第一条交易开始一直到该交易列表的最后一条交易，执行下面历史交易的重演核验操作；

S124,判断当前业务交易是否是所要求核验的业务活动，即该交易是否会对业务活动所关联的业务信息表中的业务记录做出改动，涉及新增、删除或变更业务记录；如果不是，则返回步骤S123执行下一条交易的判断，如果是，则继续执行以下步骤；

S125,判断当前的业务交易是否被成功执行，若是，则根据被执行的操作对应变更被构造的核验凭证取值列表；如果当前的业务交易没有被成功执行，则维持被构造的核验凭证取值列表不变；

S126,返回第S123步，继续当前区块内下一个交易的处理；

S127,返回第S122步，继续链上下一个区块的处理，直至达到指定的块高或链上最新区块。

5.根据权利要求4所述的一种面向区块链的数据灾难恢复方法，其特征在于，在所述步骤S124中，通过核验交易的to地址来排除与当前所核验业务活动无关的业务交易。

6.根据权利要求2所述的一种面向区块链的数据灾难恢复方法，其特征在于，在所述步骤S13中，处置满足前述第二类关系的业务记录，不存在关键属性集能够唯一区别业务数据集中的各业务记录，构造关于关系二的核验凭证取值列表进行灾难核验，包括步骤：

S131,定义核验凭证空列表；

S132,顺序遍历链上所有区块，自块高为1的区块开始，一直到当前块高为止，对于各个区块执行下面遍历区块内全部交易的操作；

S133,遍历各区块中的全部交易，即自被选定区块中交易列表的第一条交易开始一直到该交易列表的最后一条交易，执行下面历史交易的重演核验操作；

S134,判断当前业务交易是否是所要求核验的业务活动，即该交易是否会对业务活动所关联的业务信息表中的业务记录做出改动，涉及新增、删除或变更业务记录，如果不是则返回步骤S133执行下一条交易的判断，如果是，则继续执行以下步骤；

S135,判断当前业务交易是否被成功执行，若否，则不调整被构造的核验凭证取值列表；若业务交易被成功执行，则需要依解析交易回执中得到的函数返回值中关于业务交易影响的业务记录条数，并对应各业务操作类型分别执行操作：

依S134步得到的有效业务交易详情中获取交易哈希；依交易哈希获取当前交易的交易回执；依S134步得到的业务交易所对应的合约函数，依该合约函数ABI解析上面得到的交易回执中的output信息，依解析结果判断业务交易是否执行成功；依解析交易回执中output信息得到的其他函数返回值，得到业务交易所执行的操作影响的业务记录条数；依S134解析业务交易input信息的解析结果，并结合业务交易操作影响的业务记录条数，依业务交易的操作类别对应调整核验凭证取值列表的构成；

新增操作：针对每一关键属性集的取值被添加的业务记录条数，添加对应个数该关键属性集的值到核验凭证取值列表；

删除操作：针对每一关键属性集的取值被删除的业务记录条数，从被构造的核验凭证取值列表中移除对应个数的该关键属性集的值；

更新操作：针对每一关键属性集的旧值被更新的业务记录条数，从被构造的核验凭证取值列表中变更对应个数的该关键属性集的旧值为新值；

S136,返回第S133步，继续当前区块内下一个交易的处理；

S137,返回第S132步，继续链上下一个区块的处理，直至达到指定的块高或链上最新区块。

7.根据权利要求2所述的一种面向区块链的数据灾难恢复方法，其特征在于，在所述步骤S14中，灾难核验包括步骤：

S141，经由区块链提供的API获取所关注的业务数据集中全部业务记录的关键属性集取值列表；关键属性集取值在列表中以元组存在；

S142，比较所构造核验凭证取值列表中得到的核验凭证取值列表和S141中构造的关键属性集取值列表是否一致；

若一致，则认为业务数据集中无灾难存在，即业务数据集中的业务数据所反映的区块链系统状态与链上区块所反映的区块链系统状态相一致；

若不一致，则业务数据集中的业务数据不能正确反映区块链系统的当前状态，业务数据存在灾难信息，需要执行业务数据的灾难恢复操作。

8.根据权利要求2-7任一项所述的一种面向区块链的数据灾难恢复方法，其特征在于，对于处理业务数据集中各业务记录的关键属性集取值唯一的情况，即业务记录间关系属于关系一的情景，灾难恢复包括步骤：

S211,从业务数据集中删除关键属性集取值在关键属性值取值列表且又不在核验凭证取值列表中的全部业务记录；

S212,重构关键属性集取值在核验凭证取值列表中但又不在由业务数据集的全部业务记录构造得到的关键属性集取值列表中的业务记录，并将重构得到的业务记录添加入业务信息表；重构业务记录需要依链上区块中的有效交易来重构。

9.根据权利要求2-7任一项所述的一种面向区块链的数据灾难恢复方法，其特征在于，对于处理业务数据集中各业务记录的关键属性集并不能唯一区别业务数据集中的业务记录，即业务记录间关系属于关系二的情景，灾难恢复包括步骤：

S221,当某关键属性集取值存在于关键属性集取值列表但又不存在于核验凭证取值列表的情况，执行外部操作将关键属性集取值为指定值的业务记录从业务数据集中删除；

S222,当存在某关键属性集取值在关键属性集取值列表中出现的次数多于该特定的关键属性集取值在核验凭证取值列表中出现的次数，假定关键属性集取值为a，对比一个由业务数据集中所有这些关键属性集取值为a的全部业务记录构成的列表和另一个由链上历史交易执行到当前区块引起的关键属性集取值为a的全部业务记录构成的列表；并把第一个列表中所有不在第二个列表中的业务记录从业务数据集中全部删除；

S223,当存在关键属性集取值存在于核验凭证取值列表但又不存在于关键属性集取值列表的情况，从当前区块开始逆序遍历链上区块及被打包的交易，构建特定关键属性集取值的业务记录，逆序遍历至对应业务记录的全部属性取值被确定，并将重构的业务记录添加入业务数据集；

S224,当存在关键属性集取值在关键属性集取值列表中出现的次数少于该特定的关键属性集取值在核验凭证取值列表中出现的次数，对比一个由业务数据集中所有这些关键属性集取值为a的全部业务记录构成的列表和另一个由链上历史交易执行到当前区块引起的关键属性集取值为a的全部业务记录构成的列表；并把第二个列表中所有不在第一个列表中的业务记录新增到业务数据集。

10.根据权利要求1所述的一种面向区块链的数据灾难恢复方法，其特征在于，所述业务数据的全局核验的方法包括步骤：

S31,定义一空的业务数据集实例；

S32,自起始区块顺序遍历链上全部区块直至当前区块、顺序遍历各区块交易列表中的全部交易，逐一执行有效的业务交易；

S33,依合约ABI、合约函数ABI，解析业务交易的input信息，解析交易回执的output信息，获取被成功执行的业务交易的输入参数、输出参数，依此对被构造的业务数据实例依次执行业务记录插入、删除、属性值更新等操作；

S34,跳转步骤S32，循环执行直至完成所有区块、所有有效交易的遍历，得到正确反映当前区块链系统状态的业务数据集实例；

S35，依以上构造的业务数据集实例来核验因外部注入操作引起的存在灾难的业务数据集，并消除数据差错。