CN116128658A - 基于区块链的数据存储保险方法、装置、设备及存储介质 - Google Patents

Abstract

本申请提供一种基于区块链的数据存储保险方法、装置、设备及存储介质，包括：接收服务方提供的目标投保数据和服务方数据账本，以及客户方提供的客户方数据账本。数据账本包含有目标投保数据在每个更新版本对应的记账条目，记账条目记录有本方提供的目标投保数据对应所属更新版本的摘要信息以及对方签名确认的目标投保数据对应所属更新版本的摘要信息。调用区块链的预言机执行：将服务方侧的目标投保数据与双方数据账本中的记账条目进行匹配。调用保险智能合约执行：基于记账条目的匹配结果确定保险结算清单，并向区块链提交执行保险结算清单的区块链交易。本申请在服务方替客户方存储的数据发生损坏或缺失时，可约束服务方向客户方履行赔付义务。

Description

基于区块链的数据存储保险方法、装置、设备及存储介质

技术领域

本申请涉及区块链技术领域，尤其涉及一种基于区块链的数据存储保险方法、装置、设备及存储介质。

背景技术

云存储是一种在线存储模式。云存储的服务方根据客户方的需求，在后端准备存储虚拟化的资源，并将其以存储资源池的方式提供给客户方；对应地，客户方可自行使用存储资源池在线存放数据。

现阶段，云存储这类数据存储服务没有为客户方提供有效的数据保障机制。一旦客户方委托存储的数据被服务方丢失或损坏，往往因赔付标准不明确而产生纠纷，最终结果通常是客户方自己承担损失。

为此，有必要针对数据存储类业务开发一种完善的数据保障机制，以促进生态健康发展。

发明内容

本申请目的是提供一种基于区块链的数据存储保险方法、装置、设备及存储介质，能够为客户方提供数据存储业务的安全性保障，在服务方替客户方存储的数据发生损坏或缺失时，可有效约束服务方向客户方履行赔付义务。

为了实现上述目的，本申请实施例是这样实现的：

第一方面，提供一种基于区块链的数据存储保险方法，应用于区块链中的任意节点设备，所述区块链中部署有针对目标投保数据设置的保险智能合约，所述目标投保数据是客户方请求服务方进行存储的，所述方法由所述区块链中的任意节点设备执行，包括：

接收服务方提供的目标投保数据和对应的服务方数据账本，以及客户方提供的所述目标投保数据的客户方数据账本；其中，所述服务方数据账本和所述客户方数据账本包含有所述目标投保数据在每个更新版本对应的记账条目；所述服务方数据账本中的每个更新版本的第一目标记账条目记录有所述服务方提供的目标投保数据所属更新版本的摘要信息以及所述客户方签名确认的所述目标投保数据所属更新版本摘要信息；所述客户方数据账本中的每个更新版本的第二目标记账条目记录有所述客户方提供的目标投保数据所属更新版本的摘要信息以及所述服务方签名确认的所述目标投保数据对应所属更新版本摘要信息；

调用所述区块链的预言机以执行：将所述服务方提供的所述目标投保数据，与所述服务方数据账本和所述客户方数据账本中的记账条目进行匹配，得到记账条目的匹配结果；

调用所述保险智能合约以执行：基于所述记账条目的匹配结果确定保险结算清单，并向区块链提交执行所述保险结算清单的区块链交易；其中，所述保险结算清单包括所述客户方向所述服务方支付的保费资源和/或所述服务方向所述客户方支付的理赔资源。

第二方面，提供一种基于区块链的数据存储保险装置，应用于区块链中的任意节点设备，所述区块链部署有针对目标投保数据设置的保险智能合约，所述装置包括：

接收模块，用于接收服务方提供的目标投保数据和对应的服务方数据账本，以及客户方提供的所述目标投保数据的客户方数据账本；其中，所述服务方数据账本和所述客户方数据账本包含有所述目标投保数据在每个更新版本对应的记账条目；所述服务方数据账本中的每个更新版本的第一目标记账条目记录有所述服务方提供的目标投保数据所属更新版本的摘要信息以及所述客户方签名确认的所述目标投保数据所属更新版本摘要信息；所述客户方数据账本中的每个更新版本的第二目标记账条目记录有所述客户方提供的目标投保数据所属更新版本的摘要信息以及所述服务方签名确认的所述目标投保数据对应所属更新版本摘要信息；

匹配模块，用于调用所述区块链的预言机以执行：将所述服务方提供的所述目标投保数据，与所述服务方数据账本和所述客户方数据账本中的记账条目进行匹配，得到记账条目的匹配结果；

结算模块，用于调用所述保险智能合约以执行：基于所述记账条目的匹配结果确定保险结算清单，并向区块链提交执行所述保险结算清单的区块链交易；其中，所述保险结算清单包括所述客户方向所述服务方支付的保费资源和/或所述服务方向所述客户方支付的理赔资源。

第三方面，本申请实施例提供了一种电子设备，包括：处理器；以及，被配置为存储计算机可执行指令的存储器，所述计算机可执行指令在被执行时使所述处理器执行第一方面所述的方法。

第四方面，提供一种计算机可读存储介质，所述计算机可读存储介质用于存储计算机可执行指令，所述计算机可执行指令在被处理器执行时实现第一方面所述的方法。

基于本申请的方案，客户方可以对请求存储的数据进行投保，并将投保数据对应的保险智能合约部署在区块链中。同时，客户方和服务方都要针对投保数据维护各自的数据账本，以记录本方提供的投保数据在每个更新版本对应摘要信息以及对方签名确认的目标投保数据对应每个更新版本的摘要信息，也就是双方提供的投保数据的摘要信息需要签名确认后分享给另一方，从而在相互签名确认的约束下防止摘要信息后续被恶意篡改，使得双方数据账本可以有效举证每个更新版本下的投保数据。在需要保险结算时，由区块链去中心化的预言机根据客户方和服务方的数据账本，与服务方实际存储的目标投保数据进行匹配，以保证匹配结果具有客观性。其中，服务方和客户方的数据账本会针对投保数据的每个更新版本配置相对应的记账条目以记录摘要信息，通多对比可以发现在哪个更新版本开始服务方未能正确存储客户方的投保数据。之后，调用保险智能合约按照预言机提供的匹配结果来确定保险结算清单，比如根据服务方正确存储的更新版本确定客户方需要向所述服务方支付的保费资源，或者根据服务方未能正确存储的更新版本确定服务方需要向客户方支付的理赔资源，因此具有明确的赔付标准。可以看出，本申请的方案为客户方提供一种有效的数据保障机制，在服务方替客户方存储的数据发生损坏或缺失时，可有效约束服务方向客户方履行赔付义务；同时，还支持客户方对投保数据进行更新，具有更高的实用性。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请实施例中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例基于区块链的数据存储保险方法的流程示意图。

图2为本申请实施例基于区块链的数据存储保险方法的数据账本的示意图。

图3为本申请实施例基于区块链的数据存储保险方法的架构示意图。

图4为本申请实施例基于区块链的数据存储保险装置的结构示意图。

图5为本申请实施例的电子设备的结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本说明书一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本说明书保护的范围。

如前所述，目前数据存储服务同样没有为客户方提供有效的数据保障机制。一旦客户方委托存储的数据被服务方丢失或损坏，往往因赔付标准不明确而与服务方产生纠纷，最终结果往往是客户自己承担损失。特别是在使用数据存储服务的过程中，客户方对已经存储的数据有合理的更新需求，而存储的数据经常发生变化也会给理赔带来举证上的难度。

鉴于此，本申请旨在基于区块链技术，提供一种针对数据存储的理赔机制，一旦服务方替客户方存储的数据发生损坏或缺失时，可有效约束服务方向客户方履行赔付义务。

具体地，本申请中，客户方可以对请求存储的数据进行投保，并将投保数据对应的保险智能合约部署在区块链中。同时，客户方和服务方都要针对投保数据维护各自的数据账本，以记录本方提供的投保数据在每个更新版本对应摘要信息以及对方签名确认的目标投保数据对应每个更新版本的摘要信息，也就是双方提供的投保数据的摘要信息需要签名确认后分享给另一方，从而在相互签名确认的约束下防止摘要信息后续被恶意篡改，使得双方数据账本可以有效举证每个更新版本下的投保数据。在需要保险结算时，由区块链去中心化的预言机根据客户方和服务方的数据账本，与服务方实际存储的目标投保数据进行匹配，以保证匹配结果具有客观性。其中，服务方和客户方的数据账本会针对投保数据的每个更新版本配置相对应的记账条目以记录摘要信息，通多对比可以发现在哪个更新版本开始服务方未能正确存储客户方的投保数据。之后，调用保险智能合约按照预言机提供的匹配结果来确定保险结算清单，比如根据服务方正确存储的更新版本确定客户方需要向所述服务方支付的保费资源，或者根据服务方未能正确存储的更新版本确定服务方需要向客户方支付的理赔资源，因此具有明确的赔付标准。可以看出，本申请的方案为客户方提供一种有效的数据保障机制，在服务方替客户方存储的数据发生损坏或缺失时，可有效约束服务方向客户方履行赔付义务。同时，还支持客户方对投保数据进行更新，具有更高的实用性。

基于上述方案原理，一方面，本申请实施例提供一种基于区块链的数据存储保险方法，该数据存储保险方法可以由区块链中的任意节点设备执行。区块链已部署针对目标投保数据设置的保险智能合约。其中，目标投保数据是客户方请求服务方进行存储的数据对象，保险智能合约包含有目标投保数据的理赔逻辑。理赔逻辑可以但不限于是目标投保数据的理赔资源价格，是客户方根据目标投保数据的重要性与服务方预先约定的，这里本文不作具体限定。

参考图1，图1为本申请实施例提供的数据存储保险方法的流程示意图，包括如下步骤：

S102，接收服务方提供的目标投保数据和对应的服务方数据账本，以及客户方提供的目标投保数据的客户方数据账本；其中，服务方数据账本和客户方数据账本包含有目标投保数据在每个更新版本对应的记账条目；服务方数据账本中的每个更新版本的第一目标记账条目记录有服务方提供的目标投保数据所属更新版本的摘要信息以及客户方签名确认的目标投保数据所属更新版本摘要信息；客户方数据账本中的每个更新版本的第二目标记账条目记录有客户方提供的目标投保数据所属更新版本的摘要信息以及服务方签名确认的目标投保数据对应所属更新版本摘要信息。

本申请中，服务方提供的目标投保数据为服务方当前存储的最新版本的目标投保数据。

客户方数据账本是指客户方针对目标投保数据所维护的数据账本。参考图2所示，客户方数据账本对应目标投保数据的每个更新版本都会生成一个记录条目，每个记录条目记录有客户方举证的目标投保数据对应所属更新版本的摘要信息，以及服务方签名确认的属更新版本的摘要信息。例如：客户方数据账本的记录条目1记录有本方提供的目标投保数据对应更新版本1的摘要信息以及服务方签名确认的目标投保数据对应更新版本1的摘要信息；客户方数据账本的记录条目2记录有本方提供的目标投保数据对应更新版本2的摘要信息以及服务方签名确认的目标投保数据对应更新版本2的摘要信息；客户方数据账本的记录条目3记录有本方提供的目标投保数据对应更新版本3的摘要信息以及服务方签名确认的目标投保数据对应更新版本3的摘要信息。

同理，服务方数据账本是指服务方针对目标投保数据所维护的数据账本。继续参考图2所示，服务方数据账本对应目标投保数据的每个更新版本都会生成一个记录条目，每个记录条目记录有服务方举证的目标投保数据对应所属更新版本的摘要信息，以及客户方签名确认的所属更新版本的摘要信息。例如：服务方数据账本的记录条目1记录有本方提供的目标投保数据对应更新版本1的摘要信息以及客户方签名确认的目标投保数据对应更新版本1的摘要信息；服务方数据账本的记录条目2记录有本方提供的目标投保数据对应更新版本2的摘要信息以及客户方签名确认的目标投保数据对应更新版本2的摘要信息；服务方数据账本的记录条目3记录有本方提供的目标投保数据对应更新版本3的摘要信息以及客户方签名确认的目标投保数据对应更新版本3的摘要信息。

应理解，摘要信息是对目标投保数据进行加密所生成的(可以使用MD5、SHA-1、SHA-256等常见的哈希加密算法)。一旦目标投保数据发生变化，对应的摘要信息也会发生改变，因此摘要信息也可以代表目标投保数据的内容。对于客户方和服务方中任意一方而言，在将本方签名确认目标投保数据的摘要信息提供给对方后，如果后续对目标投保数据和/或对应的摘要信息进行篡改，都会导致与对方记录条目记录的信息不匹配，因此可以有效遏制客户方和服务方篡改摘要信息的作恶行为。

需要说明的是，本申请数据账本中记账条目不限于只记录目标投保数据对应所属更新版本的摘要信息。

作为示例性介绍，客户方预先向保险智能合约抵押保费担保资源。在结算时，保险智能合约从保费担保资源中扣除保费资源支付给服务方的电子钱包。对应地，参考图2所示，双方数据账本的记账条目还可以记录有保费担保资源在所属更新版本下对应的理论余额以及对方签名确认的所述保费担保资源在所属更新版本下对应的理论余额。其中，这里所述的理论余额是在指服务方正确存储目标投保数据的假设下，保费担保资源扣除应支付的保费资源后所剩下的余额资源。

应理解，在记账条目记录理论余额后，双方数据账本还可以客户方理论支付保费进行对账。对于客户方和服务方中任意一方而言，如果恶意提供缺少记账条目的数据账本，都会导致客户方理论支付的保费对不上账，从而遏制了擅自添加或删除记账条目的作恶行为。

这里以图2中所示的双方数据账本为示例。假设服务方擅自删除记了本方数据装备中的记账条目3，导致服务方数据账本的理赔账单与客户方数据账本不一致，但通过客户方数据账本却发现，其记账条目3记录有服务方针对更新版本3签名确认的理论余额，则表示服务方一开始承认更新版本3对应的目标投保数据。即便后来服务方因更新版本3对应的目标投保数据未能正确存储，而删除掉本方数据账本的记账条目3，也无法在客户方数据账本的记账条目3的举证下，进行掩饰。

此外，如果客户方与服务方约定使用非对称算法进行签名确认，则任意一方可以使用自己的非临时私钥，生成一对临时私钥和临时公钥，并使用临时私钥进行签名确认。对应地，参考图2所示，任意一方数据账本中的记账条目还可以记录有本方用于签名确认的临时私钥和该临时私钥对应的临时公钥。这一样来，预言机可以根据客户方数据账本中的客户方的临时公钥，对服务方提供的由客户方私钥签名确认的摘要信息和/或理论余额进行解析；反之，根据服务方数据账本中的服务方的临时公钥，对客户方提供的由服务方私钥签名确认的摘要信息和/或理论余额进行解析。需要说明的是，私钥签名确认相当于是使用临时私钥进行信息加密，对于预言机而言，如果需要读取私钥签名确认后的信息，需要使用相匹配的临时公钥进行解析。

在实际应用中，客户方和服务可以方针对不同更新版本的目标投保数据配置有专属的用于签名确认的临时私钥。比如图2所示，客户方针对更新版本1生成一对临时公钥-临时私钥A1，服务方针对更新版本1生成一对临时公钥-临时私钥B1；客户方针对更新版本2生成一对临时公钥-临时私钥A2，服务方针对更新版本2生成一对临时公钥-临时私钥B2；客户方针对更新版本3生成一对临时公钥-临时私钥A3，服务方针对更新版本3生成一对临时公钥-临时私钥B3。

对于客户方和服务方中任意一方而言，每当目标投保数据产生出新的更新版本后，可以将上一更新版本用于签名确认的临时私钥公开给对方以表示作废；对应地，服务方数据账本和客户方数据账本中非初始更新版本的记账条目还可以记录有对方在上一更新版本用于签名确认的临时私钥。例如图2中，在目标投保数据迭代至更新版本2后，客户方数据账本的记账条目记录有服务方在更新版本1所使用的临时私钥B1，服务方数据账本的记账条目记录有客户方在更新版本1所使用的临时私钥A1；在目标投保数据迭代至更新版本3后，客户方数据账本的记账条目记录有服务方在更新版本1所使用的临时私钥B2，服务方数据账本的记账条目记录有客户方在更新版本1所使用的临时私钥A2。

需要说明的是，如果服务方针对客户方发起的不同类型的更新操作(如增加、修改、删除)设置有不同的更新手续费用，则参考图2所示，任意一方数据账本中的记账条目还可以记录有对应的更新操作类型或者与更新操作类型相匹配的更新手续费用(图2以记录更新手续费用为示例)。这样一来，在结算时，保险智能合约还可以根据双方数据账本中记账条目，计算出客户方需要向服务方支付的所有更新手续费资源。对于本申请而言，更新手续费资源也可以属于保险结算清单。

这里以图2中所示的双方数据账本为示例。假设更新版本1为目标投保数据的初始更新版本，由于初始更新版本没有相对应的更新操作，因此双方数据账本记录条目1的更新收费用1记录为0。之后，客户方向服务方提出了在目标投保数据添中加新数据的更新要求，假设服务方针对数据新增的更新操作收费为0.5数字代币，则在完成数据新增后，目标投保数据的更新版本由1迭代至2，双方数据账本对应生成记录条目2，记录条目2中记的更新收费用2为0.5数字代币。再之后，客户方向服务方提出了修改目标投保数据的更新要求，假设服务方针对数据修改的更新操作收费为0.8数字代币，则在完成数据修改后，目标投保数据的更新版本由2迭代至3，双方数据账本对应生成记录条目3，记录条目3中记的更新收费用3为0.8数字代币；对于保险智能合约而言，只需要各对记录条目中所有更新手续费用进行叠加，即可确定客户方最终需要支付的总更新手续费用。

当然，如果服务方针对不同类型的更新操作设置有统一的更新手续费用，则双方数据账本的记账条目可以不再记录更新收费费用，而是将更新手续费用的收费规则配置在保险智能合约，由保险智能合约直接根据更新版本数量来计算客户方最终需要支付的总更新手续费用。比如，服务方针任意类型的更新操作收费为1数字代币，目标投保数据对应有8个更新版本，除去初始更新版本外，实际发生的更新操作为7，对应的总更新手续费用为7×1＝7数字代币。

S104，调用区块链的预言机以执行：将服务方提供的目标投保数据，与服务方数据账本和客户方数据账本中的记账条目进行匹配，得到记账条目的匹配结果。

预言机本质上是一种数据调用和访问的中间件，可以将区块链外的数据提供给区块链中的智能合约进行处理。现有的预先机可以提供计算服务，计算服务是由区块链中的多方节点设备协同完成的，每个节点设备都需确定自己的计算结果，并广播自己的计算结果与其他节点设备进行共识。可以看出，预言机的计算服务具有去中心化和客观性的优点。对于本申请而言，需要在预言机中部署用于将服务方提供的目标投保数据，与服务方数据账本和客户方数据账本中的记账条目进行匹配的计算服务。在需要匹配时，只需要调用预言机将服务方提供的目标投保数据，以及双方数据账本导入至预言机即可执行计算服务。对应地，预言机在确定记账条目的匹配结果后，会将匹配结果提供至保险智能合约，由保险智能合约确定保险结算清单以完成最终的结算。

在具体的匹配过程中，先生成服务方提供的目标投保数据的目标摘要信息；之后，按照更新版本由新到旧的顺序，在服务方数据账本和客户方数据账本中选取记账条目与生成的目标摘要信息进行匹配，直至匹配成功或者所有更新版本的记账条目均匹配失败后结束。其中，任意更新版本匹配成功是指在该更新版本下，服务方数据账本中记账条目记录的所述服务方提供的摘要信息以及所述客户方数据账本中记账条目记录的所述客户方提供的摘要信息同时与所述目标摘要信息一致。

下面对预言机进行匹配的原理进行介绍。

基于前文所述，双方数据账本在相互签名约束下，无法随意缺失或添加任何更新版本的记账条目，因此正常情况下，服务方数据账本和客户方数据账本中记录的更新版本是一致的。

这里，假设更新版本按照从旧到新依次为更新版本1、2、3、4。由于服务方提供的是最新版本的目标投保数据，因此在匹配过程中，先从双方数据账本中提取更新版本4对应的记账条目，并基于双方更新版本4记账条目中所记录的摘要信息，与服务方提供的目标投保数据(目标摘要信息)进行匹配校验；如果目标投保数据与双方更新版本4记账条目中所记录的摘要信息不匹配，则再从双方数据账本中提取更新版本3对应的记账条目，并基于双方更新版本3记账条目中所记录的摘要信息，与服务方提供的目标投保数据进行匹配校验；如果目标投保数据依然与双方更新版本3记账条目中所记录的摘要信息不匹配，则再从双方数据账本中提取更新版本2对应的记账条目，并基于双方更新版本2记账条目中所记录的摘要信息，与服务方提供的目标投保数据进行匹配校验；……直至匹配成功，或目标投保数据与双方更新版本1记账条目中所记录的摘要信息不匹配后结束。

其中，如果一方恶意丢失一个更新版本的记账条目，比如服务方数据账本缺少版本4的记账条目，则直接默认版本4的记账条目匹配失败；

此外，如果服务方提供的目标投保数据至于其中一方记账条目中所记录的摘要信息匹配，则存在下述两种情况：

情况1：服务方提供恶意篡改后的摘要信息，也就是服务方未正确存储目标投保数据，但不想进行理赔；

情况2：客户方提供恶意篡改后的摘要信息，也就是服务方正确存储目标投保数据，但客户方尝试骗保。

不管上述哪种情况发生，由于之前服务方和客户方均将自己签名确认后的摘要信息提交给对方，即便之后恶意篡改都会与自己之前签名确认过的摘要信息不符，在后续可以被追溯出来。

对于本申请而言，预言机在确认各更新版本记账条目的匹配结果后，可以将匹配结果发给双方进行确认。如果有一个方不认可匹配结果，则可以通过双方数据账本发起第三方的人工审核，对于人工审核而言，在双方数据账本相互签名的约束下，可直接确定出作恶的一方；如果双方认可匹配结果，则预言机再进一步将匹配结果提交至保险智能合约。

进一步地，在人工审核确定出作恶的一方后，审核人员可以通过区块链节点向预言机提交作恶一方的信息，由预言机进一步将作恶一方的信息提交给保险智能合约。保险智能合约配置有处罚的执行逻辑，可以对作恶一方进行相应的处罚。比如，若客户方作恶，则保险智能合约可以通过提交区块链交易的方式，将之前客户方抵押的保费担保资源全部或部分转入至服务方的电子钱包；同理，服务方也可以预先向保险智能合约抵押理赔担保资源，若服务方作恶，则保险智能合约通过提交区块链交易的方式，将之前服务方抵押的理赔担保资源全部或部分转入至客户方的电子钱包。

S106，调用保险智能合约以执行：基于记账条目的匹配结果确定保险结算清单，并向区块链提交执行保险结算清单的区块链交易；其中，保险结算清单包括客户方向服务方支付的保费资源和/或服务方向客户方支付的理赔资源。

本申请中，保险智能合约针对每个更新版本的记账条目可以设置有独立的保费资源和理赔资源，从而能够以更新版本为粒度结算保费资源和理赔资源。

如前所述，预言机的计算服务会按照更新版本由新到旧的顺序，在服务方数据账本和客户方数据账本中选取记账条目与生成的摘要信息进行匹配，直至匹配成功或者所有更新版本的记账条目均匹配失败后结束。

如前所述，预言机的计算服务会按照更新版本由新到旧的顺序，在服务方数据账本和客户方数据账本中选取记账条目与生成的摘要信息进行匹配，直至匹配成功或者所有更新版本的记账条目均匹配失败后结束。对于本申请实施例而言，可以基于匹配失败的更新版本的记账条目，确定服务方向客户方支付的理赔资源，并基于匹配成功的更新版本的记账条目以及未进行匹配的更新版本的记账条目，确定客户方向所述服务方支付的保费资源。

作为示例性介绍，假设更新版本按照从旧到新的依次为更新版本1、2、3、4、5，预言机首先从双方数据账本中提取更新版本5的记账条目所记录的摘要信息与目标投保数据进行匹配；如果匹配失败，则再从双方数据账本中提取更新版本4的记账条目所记录的摘要信息与目标投保数据进行匹配，并以此类推……。这里，进一步假设服务方提供的目标投保数据与双方数据账本中更新版本3所对应的记账条目所记录的摘要信息匹配成功，则说明服务方在更新版本1-3均正确存储了目标投保数据，但在更新版本4开始未能正确存储目标投保数据。此时，直接结束匹配，更新版本1、2为未进行匹配的更新版本。本申请对更新版本1-3记账条目对应的保费资源进行汇总，确定客户方最终需要向服务方支付的所有保费资源，即客户方向服务方支付的保费资源为匹配成功的更新版本(更新版本3)的记账条目与未进行匹配的更新版本(更新版本1、2)的记账条目所对应的保费资源之和；同时，将更新版本4、5记账条目对应的理赔资源进行汇总，确定为服务方最终需要向客户方支付的理赔资源，即服务方向客户方支付的理赔资源为匹配失败的更新版本(更新版本4、5)的记账条目所对应的理赔资源之和。

此外，如果服务方针对客户方的更新操作设置有额外费用，则保险智能合约确定的保险结算清单中还可以包含有客户方需要向服务方支付的更新手续费资源。其中，所述客户方向所述服务方支付的更新手续费资源为匹配成功的更新版本的记账条目与未进行匹配的更新版本的记账条目所对应的更新手续费资源之和。

作为示例性介绍，假设更新版本按照从旧到新的依次为更新版本1、2、3、4、5，服务方在更新版本1-3均正确存储目标投保数据，但在更新版本4开始未能正确存储目标投保数据，则客户方最终需要向服务方支付的更新手续费资源应是更新版本1、2、3对应的更新手续费资源之和。其中，如果服务方对初始更新版本不收取更新手续费资源，则更新版本1对应的更新手续费资源应默认设置为0。

此外，保险智能合约配置有处罚执行逻辑，如果预言机提交的是作恶一方的信息，则保险智能合可以对作恶一方进行相应的处罚，这里文本不再赘述。

下面对本申请实施例的数据存储保险方法的实际应用进行介绍。

本申请中，服务方向客户方提供数据存储服务。客户方基于数据存储的服务应用，向服务方申请存储资源池，以在线存储数据；同时，客户方还可以随时通过服务应用，向服务方发起针对存储数据的更新操作。此外，服务方为了向客户方证明其数据存储的可信度，向客户方提供存储数据的保险服务。如果客户方对保险服务有需求，可以与服务方需要协商制定数据保险规则。

其中，数据保险规则包括以下几个方面：

1)保费上限额度和理赔上限额度；

保费上限额度是指需要客户方提前向保险智能合约抵押的保费担保资源，理赔上限额度是指需要服务方提前向保险智能合约抵押的理赔担保资源。例如用户一次性质押100元的保费担保金，保费和理赔的比例根据数据重要性的不同而不同，这里假定是1:10，那么服务方需要对应质押1000元的理赔金在保险智能合约里面。

2)结算周期上限；

为避免服务方一直得不到保费，保险需要定期结算。之所以协商结算周期的上限，而不是以固定周期进行结算，是因为有提前结算的可能性。比如，在双方记账过程中发现，客户方的保费担保资源已经没有余额了，此时结算周期还没有到，就需要提前进行结算。

3)确定保险标的；

由于存储数据有着新增、删除、修改的需要，因此有以下方法确定保险标的：

方法1，将整个目标投保数据定义为一个保险标的，比如关系型数据库中可以是一张表，非关系数据库中可以是一个集合，根据数据的大小设置保费，此外对于更新操作设置一个更新手续费用，更新操作可以是新增、修改、删除等，不同更新操作的更新手续费用可以相同，也可以不同，这里不作具体限定。

方法2，将目标投保数据中的子数据定义为保险标的，创建的时候设置一个保费，此外对于更新操作设置一个更新手续费用。同理，不同更新操作的更新手续费用可以相同，也可以不同。

在保险规则协商完成后，服务方基于保险规则生成保险智能合约，并提交给客户方进行签名确认。在客户方签名确认后，服务方将保险智能合约部署至区块链。其中，保险智能合约的赋能如下：

1)保险智能合约可以接收来自于服务方数字钱包地址转入的理赔金，并且服务方可以对保险智能合约发起主动结算请求。

2)保险智能合约可以接收来自于客户方数字钱包地址转入的保费，并且客户方可以对保险智能合约发起主动结算请求。

3)保险智能合约会在结算周期到达上限的时候自动结算，例如，结算上限周期为1周，一周内没有服务方发起结算请求，也没有客户方发起理赔请求，保险智能合约会自动结算。

在区块链部署保险智能合约后，客户方和服务方各自对目标投保数据进行记账。其中，记账是以保险标的为单位，单个保险标的对应的记账流程如下：

1)记账数据初始化。

其中，初始化内容包括：

(1)保险标的对应的摘要信息；如果当前保险标的还没有数据，可以将字符串“NULL”、“[]”这类空数组视为保险标的，以生成对应的摘要信息。

(2)保费担保资源的理论余额；

(3)本方(客户方或服务方)的临时公钥、临时私钥；临时公钥可以通过自己的数字钱包的非临时私钥进行签名授权，也就是说，客户方(或服务方)的临时公钥、临时私钥本身就可以证明是源自客户方的。

(4)使用本方的临时私钥对(1)(2)两项数据进行签名，并提交给对方。

其中，客户方数据账本中的任意目标更新版本的记账条目是客户方确认满足以下条件时所生成的：

服务方签名确认的目标投保数据对应目标更新版本的摘要信息与本方向服务方请求存储的目标更新版本下的所述目标投保数据相匹配；和/或，服务方签名确认的保费担保资源在目标更新版本下对应的理论余额与本方确定的保费担保资源在目标更新版本下对应的理论余额相匹配。

也就是说，针对某一个目标更新版本，客户方在接收到服务方签名确认的(1)(2)两项数据后，需要检查服务方签名确认的(1)(2)两项数据与本方所确定的1)(2)两项数据是否一致；如果一致，则客户方在客户方数据账本中生成该目标更新版本的记账条目。如果不一致，则服务方有作恶嫌疑，客户方可以终止服务发起主动结算请求。

同理，服务方数据账本中的任意目标更新版本的记账条目是服务方确认满足以下条件时所生成的：

服务方签名确认的目标投保数据对应所述目标更新版本的摘要信息与本方存储的目标更新版本下的目标投保数据相匹配；和/或，服务方签名确认的所述保费担保资源在目标更新版本下对应的理论余额与本方确定的保费担保资源在目标更新版本下对应的理论余额相匹配。

也就是说，针对某一个目标更新版本，服务方在接收到客户方签名确认的(1)(2)两项数据后，需要检查客户方签名确认的(1)(2)两项数据与本方所确定的1)(2)两项数据是否一致；如果一致，则服务方在服务方数据账本中生成该目标更新版本的记账条目。如果不一致，则客户方有作恶嫌疑，服务方可以终止服务发起主动结算请求。

2)客户方向服务方发起针对目标投保数据的更新操作(新增、修改、删除等)，开始对目标投保数据进行新一更新版本的记账，记账流程如下：

(1)更新后保险标的对应的摘要信息。

其中，保险标的可以是指整个目标投保数据，或者目标投保数据中每个子数据可以单独作为一个保险标的。

(2)保费担保资源的理论余额；

其中，客户方上一次记录的理论余额与本次记录的理论余额之间的差值作为客户方的支出；服务方上一次记录的理论余额与本次记录的理论余额之间的差值作为服务方的收入；

(3)本方(客户方或服务方)在本次更新版本所使用的临时公钥、临时私钥；

其中，本次更新版本所使用的临时公钥、临时私钥不同于上一更新版本所使用的临时公钥、临时私钥。

参考图3所示的架构，在需要结算时，不论发起方是客户方还是服务方，或者是自动结算，都需要客户方和服务方向区块链节点发起预言机的调用请求。其中，客户方的调用请求携带有客户方数据账本，服务方的调用请求携带有服务方数据账本以及服务方实际存储的目标投保数据。对应地，区块链节点在接收到任意一方的调用请求后，将其提供的数据输入至预言机，以有预言机完成计算服务。

其中，本申请的预言机会按照结算周期上限来自动触发计算服务，或者，在接收到一方提出的结算请求后后触发计算服务。在计算服务触发后，预言机开始启动内部设定的计时器进行计时。

如果有一方在要求时间内未提交数据账本，则预言机将超时未提交数据账本的结果提交到保险智能合约，由保险智能合约按提交数据账本的一方的要求来处理结算。例如，用户方提交账本，交了保费10元，该保险的赔偿比例1:10，服务方未按要求提交账本，则用户方可以将保费10元和赔偿金100元转入自己的数字钱包。反之，服务方可以将10元保费转入自己的数字钱包。

如果双方均按时提交数据账本，则预言机的计算服务根据服务端提交的目标投保数据，生成各保险标的对应的摘要信息，并使用生成的摘要信息与双方数据账本里面的摘要信息进行匹配。匹配过程如前文所述，是按照更新版本由新到旧的顺序，在服务方数据账本和客户方数据账本中选取记账条目与生成的摘要信息进行匹配，直至匹配成功或者所有更新版本的记账条目均匹配失败后结束。

之后，预言机若一次就匹配成功，则可以直接将匹配结果提交给保险智能合约，由保险智能合约根据各保险标的对应的保费资源计算总保费，并从客户方之前抵押的保费担保资源中扣除对应的数额以转入至服务方的数字钱包中。预言机若未能一次就匹配成功，则将匹配结果反馈至区块链节点，由区块链节点通知客户方和服务方进行确认。在双方无异议的情况下，则区块链节点调用预言机将匹配结果提交到保险智能合约，由保险智能合约确定保险结算清单，也就是基于所有匹配失败的更新版本的记账条目，确定服务方需要向客户方支付的理赔资源；基于匹配成功的更新版本的记账条目以及未进行匹配的更新版本的记账条目，确定客户方需要向所述服务方支付的保费资源和更新手续费用。

基于上述内容可以看出，本申请实施例的数据存储保险方法具有以下特点：

1)为存储数据细分出保险标的，并指定险标的赔付比例，把对数据丢失、数据被篡改的赔付提前制定好。

2)用户可以自行对重要和非重要的数据进行分级，对于数据不同的分级投入不同的保费，通过这样的方式告知服务方，哪些数据是客户方比较重要的数据，需要对于安全性、完整性加强管理。

3)通过预言机的计算服务来确定出保险结算的依据，并由智能合约替提交完成保险结算的区块链交易，也就是保费、理赔的判定是由区块链完成的，而非服务方，即便客户不信任服务方，但区块链是绝对去中心化的。

4)保险智能合约周期性结算，每个周期内处理一批更新操作对应的数据账本，这样就不会因为保险标的变化频率较快导致保险智能合约被频繁调用。

5)通过数字钱包的签名和临时公钥私钥的签名的方式，维护了一个由双方可信任的数据记账过程，无需引入第三方进行见证，记账十分高效。

与上述图1所示方法相对应地，本申请实施例还提供一种基于区块链的数据存储保险装置。图4是本申请实施例数据存储保险装置400的结构示意图，包括：

接收模块410，用于接收服务方提供的目标投保数据和对应的服务方数据账本，以及客户方提供的所述目标投保数据的客户方数据账本；其中，所述服务方数据账本和所述客户方数据账本包含有所述目标投保数据在每个更新版本对应的记账条目；所述服务方数据账本中的每个更新版本的第一目标记账条目记录有所述服务方提供的目标投保数据所属更新版本的摘要信息以及所述客户方签名确认的所述目标投保数据所属更新版本摘要信息；所述客户方数据账本中的每个更新版本的第二目标记账条目记录有所述客户方提供的目标投保数据所属更新版本的摘要信息以及所述服务方签名确认的所述目标投保数据对应所属更新版本摘要信息。

匹配模块420，用于调用所述区块链的预言机以执行：将所述服务方提供的所述目标投保数据，与所述服务方数据账本和所述客户方数据账本中的记账条目进行匹配，得到记账条目的匹配结果。

结算模块430，用于调用所述保险智能合约以执行：基于所述记账条目的匹配结果确定保险结算清单，并向区块链提交执行所述保险结算清单的区块链交易；其中，所述保险结算清单包括所述客户方向所述服务方支付的保费资源和/或所述服务方向所述客户方支付的理赔资源。

基于本申请的装置，客户方可以对请求存储的数据进行投保，并将投保数据对应的保险智能合约部署在区块链中。同时，客户方和服务方都要针对投保数据维护各自的数据账本，以记录本方提供的投保数据在每个更新版本对应摘要信息以及对方签名确认的目标投保数据对应每个更新版本的摘要信息，也就是双方提供的投保数据的摘要信息需要签名确认后分享给另一方，从而在相互签名确认的约束下防止摘要信息后续被恶意篡改，使得双方数据账本可以有效举证每个更新版本下的投保数据。在需要保险结算时，由区块链去中心化的预言机根据客户方和服务方的数据账本，与服务方实际存储的目标投保数据进行匹配，以保证匹配结果具有客观性。其中，服务方和客户方的数据账本会针对投保数据的每个更新版本配置相对应的记账条目以记录摘要信息，通多对比可以发现在哪个更新版本开始服务方未能正确存储客户方的投保数据。之后，调用保险智能合约按照预言机提供的匹配结果来确定保险结算清单，比如根据服务方正确存储的更新版本确定客户方需要向所述服务方支付的保费资源，或者根据服务方未能正确存储的更新版本确定服务方需要向客户方支付的理赔资源，因此具有明确的赔付标准。可以看出，本申请的方案为客户方提供一种有效的数据保障机制，在服务方替客户方存储的数据发生损坏或缺失时，可有效约束服务方向客户方履行赔付义务。同时，还支持客户方对投保数据进行更新，具有更高的实用性。

可选地，匹配模块420将所述服务方提供的所述目标投保数据，与所述服务方数据账本和所述客户方数据账本中的记账条目进行匹配，包括：

生成所述服务方提供的所述目标投保数据的目标摘要信息；

按照更新版本由新到旧的顺序，依次在所述服务方数据账本和所述客户方数据账本中选取记账条目与所述目标摘要信息进行匹配，直至匹配成功，其中，任意更新版本匹配成功是指在该更新版本下，所述服务方数据账本中记账条目记录的所述服务方提供的摘要信息以及所述客户方数据账本中记账条目记录的所述客户方提供的摘要信息同时与所述目标摘要信息一致；或者，

按照更新版本由新到旧的顺序，依次在所述服务方数据账本和所述客户方数据账本中选取记账条目与所述目标摘要信息进行匹配，直至匹配失败，所述匹配失败是指目标摘要信息与所有更新版本的记账条目均匹配失败。

可选地，所述保险智能合约针对每个更新版本的记账条目设置有独立的保费资源和理赔资源；结算模块430基于所述记账条目的匹配结果确定保险结算清单，包括：基于匹配失败的更新版本的记账条目，确定所述服务方向所述客户方支付的理赔资源，其中，所述服务方向所述客户方支付的理赔资源为匹配失败的更新版本的记账条目所对应的理赔资源之和；和/或，基于匹配成功的更新版本的记账条目以及未进行匹配的更新版本的记账条目，确定所述客户方向所述服务方支付的保费资源，其中，所述未进行匹配的更新版本是指在所述匹配成功的更新版本之前的更新版本。

其中，所述保险智能合约针对每个更新版本的记账条目设置有独立的更新手续费用；结算模块430基于所述记账条目的匹配结果确定保险结算清单，包括：基于匹配成功的更新版本的记账条目以及未进行匹配的更新版本的记账条目，确定所述客户方向所述服务方支付的保费资源。

可选地，所述服务方数据账本和所述客户方数据账本中的记账条目还记录有所属更新版本对应的更新手续费资源；结算模块430基于所述记账条目的匹配结果确定保险结算清单，还包括：对匹配成功的更新版本的记账条目以及未进行匹配的更新版本的记账条目进行更新手续费资源汇总，确定所述客户方向所述服务方支付的更新手续费资源。

可选地，所述客户方预先向所述保险智能合约抵押有保费担保资源，所述客户方向所述服务方支付的保费资源是从抵押的所述保费担保资源中扣除；所述服务方数据账本和所述客户方数据账本中的记账条目还记录有本方提供的所述保费担保资源在所属更新版本下对应的理论余额以及对方签名确认的所述保费担保资源在所属更新版本下对应的理论余额。

可选地，所述服务方数据账本和所述客户方数据账本中的记账条目还记录有本方用于签名确认的临时私钥和该临时私钥对应的临时公钥，其中，本方用于签名确认的临时私钥和临时公钥是基于本方的非临时私钥所生成的。

可选地，所述客户方数据账本中的任意目标更新版本的记账条目是所述客户方确认满足以下条件时所生成的：

所述服务方签名确认的所述目标投保数据对应所述目标更新版本的摘要信息与本方向所述服务方请求存储的所述目标更新版本下的所述目标投保数据相匹配；和/或，所述服务方签名确认的所述保费担保资源在目标更新版本下对应的理论余额与本方确定的所述保费担保资源在目标更新版本下对应的理论余额相匹配；

可选地，所述服务方数据账本中的任意目标更新版本的记账条目是所述服务方确认满足以下条件时所生成的：

所述服务方签名确认的所述目标投保数据对应所述目标更新版本的摘要信息与本方存储的所述目标更新版本下的所述目标投保数据相匹配；和/或，所述服务方签名确认的所述保费担保资源在目标更新版本下对应的理论余额与本方确定的所述保费担保资源在目标更新版本下对应的理论余额相匹配。

可选地，所述客户方和所述服务方针对不同更新版本的所述目标投保数据配置有专属的用于签名确认的临时私钥，且在本方生成新的更新版本的所述目标投保数据后，将上一更新版本用于签名确认的临时私钥公开给对方以表示作废；所述服务方数据账本和所述客户方数据账本中非初始更新版本的记账条目还记录有对方在上一更新版本用于签名确认的临时私钥。

显然，图4所示的装置可以作为图1所示方法的执行主体，因此可以实现该方法在图1所示的步骤和相应的功能。由于原理相同，本文不再具体赘述。

此外，本申请实施例还提供一种电子设备。图5是本申请实施例电子设备的结构示意图。请参考图5，在硬件层面，该电子设备包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(Random-Access Memory，RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少1个磁盘存储器等。当然，该电子设备还可能包括其他业务所需要的硬件。

处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是ISA(Industry Standard Architecture，工业标准体系结构)总线、PCI(PeripheralComponent Interconnect，外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图5中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

存储器，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。

其中，处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成上述图5所示的数据存储保险装置。对应地，处理器，执行存储器所存放的程序，并具体用于执行以下操作：

接收服务方提供的目标投保数据和对应的服务方数据账本，以及客户方提供的所述目标投保数据的客户方数据账本；其中，所述服务方数据账本和所述客户方数据账本包含有所述目标投保数据在每个更新版本对应的记账条目；所述服务方数据账本中的每个更新版本的第一目标记账条目记录有所述服务方提供的目标投保数据所属更新版本的摘要信息以及所述客户方签名确认的所述目标投保数据所属更新版本摘要信息；所述客户方数据账本中的每个更新版本的第二目标记账条目记录有所述客户方提供的目标投保数据所属更新版本的摘要信息以及所述服务方签名确认的所述目标投保数据对应所属更新版本摘要信息。

调用所述区块链的预言机以执行：将所述服务方提供的所述目标投保数据，与所述服务方数据账本和所述客户方数据账本中的记账条目进行匹配，得到记账条目的匹配结果。

调用所述保险智能合约以执行：基于所述记账条目的匹配结果确定保险结算清单，并向区块链提交执行所述保险结算清单的区块链交易；其中，所述保险结算清单包括所述客户方向所述服务方支付的保费资源和/或所述服务方向所述客户方支付的理赔资源。

基于本申请的电子设备可知，客户方可以对请求存储的数据进行投保，并将投保数据对应的保险智能合约部署在区块链中。同时，客户方和服务方都要针对投保数据维护各自的数据账本，以记录本方提供的投保数据在每个更新版本对应摘要信息以及对方签名确认的目标投保数据对应每个更新版本的摘要信息，也就是双方提供的投保数据的摘要信息需要签名确认后分享给另一方，从而在相互签名确认的约束下防止摘要信息后续被恶意篡改，使得双方数据账本可以有效举证每个更新版本下的投保数据。在需要保险结算时，由区块链去中心化的预言机根据客户方和服务方的数据账本，与服务方实际存储的目标投保数据进行匹配，以保证匹配结果具有客观性。其中，服务方和客户方的数据账本会针对投保数据的每个更新版本配置相对应的记账条目以记录摘要信息，通多对比可以发现在哪个更新版本开始服务方未能正确存储客户方的投保数据。之后，调用保险智能合约按照预言机提供的匹配结果来确定保险结算清单，比如根据服务方正确存储的更新版本确定客户方需要向所述服务方支付的保费资源，或者根据服务方未能正确存储的更新版本确定服务方需要向客户方支付的理赔资源，因此具有明确的赔付标准。可以看出，本申请的方案为客户方提供一种有效的数据保障机制，在服务方替客户方存储的数据发生损坏或缺失时，可有效约束服务方向客户方履行赔付义务；同时，还支持客户方对投保数据进行更新，具有更高的实用性。

上述如本说明书所示实施例揭示的数据存储保险方法可以应用于处理器中，由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

当然，除了软件实现方式之外，本说明书的电子设备并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

此外，本申请实施例还提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序包括指令。

可选地，上述指令当被包括多个应用程序的便携式电子设备执行时，能够使该便携式电子设备执行图1所示方法的步骤，包括：

接收服务方提供的目标投保数据和对应的服务方数据账本，以及客户方提供的所述目标投保数据的客户方数据账本；其中，所述服务方数据账本和所述客户方数据账本包含有所述目标投保数据在每个更新版本对应的记账条目；所述服务方数据账本中的每个更新版本的第一目标记账条目记录有所述服务方提供的目标投保数据所属更新版本的摘要信息以及所述客户方签名确认的所述目标投保数据所属更新版本摘要信息；所述客户方数据账本中的每个更新版本的第二目标记账条目记录有所述客户方提供的目标投保数据所属更新版本的摘要信息以及所述服务方签名确认的所述目标投保数据对应所属更新版本摘要信息。

调用所述区块链的预言机以执行：将所述服务方提供的所述目标投保数据，与所述服务方数据账本和所述客户方数据账本中的记账条目进行匹配，得到记账条目的匹配结果。

调用所述保险智能合约以执行：基于所述记账条目的匹配结果确定保险结算清单，并向区块链提交执行所述保险结算清单的区块链交易；其中，所述保险结算清单包括所述客户方向所述服务方支付的保费资源和/或所述服务方向所述客户方支付的理赔资源。

本领域技术人员应明白，本说明书的实施例可提供为方法、系统或计算机程序产品。因此，本说明书可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本说明书可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

以上仅为本说明书的实施例而已，并不用于限制本说明书。对于本领域技术人员来说，本说明书可以有各种更改和变化。凡在本说明书的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本说明书的权利要求范围之内。此外，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本文件的保护范围。

Claims (10)

1.一种基于区块链的数据存储保险方法，其特征在于，应用于区块链中的任意节点设备，所述区块链部署有针对目标投保数据设置的保险智能合约，所述目标投保数据是客户方请求服务方进行存储的，包括：

接收服务方提供的目标投保数据和对应的服务方数据账本，以及客户方提供的所述目标投保数据的客户方数据账本；其中，所述服务方数据账本和所述客户方数据账本包含有所述目标投保数据在每个更新版本对应的记账条目；所述服务方数据账本中的每个更新版本的第一目标记账条目记录有所述服务方提供的目标投保数据所属更新版本的摘要信息以及所述客户方签名确认的所述目标投保数据所属更新版本摘要信息；所述客户方数据账本中的每个更新版本的第二目标记账条目记录有所述客户方提供的目标投保数据所属更新版本的摘要信息以及所述服务方签名确认的所述目标投保数据对应所属更新版本摘要信息；

调用所述区块链的预言机以执行：将所述服务方提供的所述目标投保数据，与所述服务方数据账本和所述客户方数据账本中的记账条目进行匹配，得到记账条目的匹配结果；

调用所述保险智能合约以执行：基于所述记账条目的匹配结果确定保险结算清单，并向区块链提交执行所述保险结算清单的区块链交易；其中，所述保险结算清单包括所述客户方向所述服务方支付的保费资源和/或所述服务方向所述客户方支付的理赔资源。

2.根据权利要求1所述的方法，其特征在于，所述调用所述区块链的预言机以执行：将所述服务方提供的所述目标投保数据，与所述服务方数据账本和所述客户方数据账本中的记账条目进行匹配，包括：

生成所述服务方提供的所述目标投保数据的目标摘要信息；

按照更新版本由新到旧的顺序，依次在所述服务方数据账本和所述客户方数据账本中选取记账条目与所述目标摘要信息进行匹配，直至匹配成功，其中，任意更新版本匹配成功是指在该更新版本下，所述服务方数据账本中记账条目记录的所述服务方提供的摘要信息以及所述客户方数据账本中记账条目记录的所述客户方提供的摘要信息同时与所述目标摘要信息一致；或者，

按照更新版本由新到旧的顺序，依次在所述服务方数据账本和所述客户方数据账本中选取记账条目与所述目标摘要信息进行匹配，直至匹配失败，所述匹配失败是指目标摘要信息与所有更新版本的记账条目均匹配失败。

3.根据权利要求2所述的方法，其特征在于，所述保险智能合约针对每个更新版本的记账条目设置有独立的保费资源和理赔资源；所述调用所述保险智能合约以执行：基于所述记账条目的匹配结果确定保险结算清单，包括：

基于匹配失败的更新版本的记账条目，确定所述服务方向所述客户方支付的理赔资源，其中，所述服务方向所述客户方支付的理赔资源为匹配失败的更新版本的记账条目所对应的理赔资源之和；和/或，

基于匹配成功的更新版本的记账条目以及未进行匹配的更新版本的记账条目，确定所述客户方向所述服务方支付的保费资源，其中，所述客户方向所述服务方支付的保费资源为匹配成功的更新版本的记账条目与未进行匹配的更新版本的记账条目所对应的保费资源之和，其中，所述未进行匹配的更新版本是指在所述匹配成功的更新版本之前的更新版本。

4.根据权利要求2所述的方法，其特征在于，

所述服务方数据账本和所述客户方数据账本中的记账条目还记录有所属更新版本对应的更新手续费资源；基于所述记账条目的匹配结果确定保险结算清单，还包括：

基于匹配成功的更新版本的记账条目以及未进行匹配的更新版本的记账条目，确定所述客户方向所述服务方支付的更新手续费资源，其中，所述客户方向所述服务方支付的更新手续费资源为匹配成功的更新版本的记账条目与未进行匹配的更新版本的记账条目所对应的更新手续费资源之和，其中，所述未进行匹配的更新版本是指在所述匹配成功的更新版本之前的更新版本。

5.根据权利要求2所述的方法，其特征在于，所述客户方预先向所述保险智能合约抵押有保费担保资源，所述客户方向所述服务方支付的保费资源是从抵押的所述保费担保资源中扣除；

所述服务方数据账本和所述客户方数据账本中的记账条目还记录有本方提供的所述保费担保资源在所属更新版本下对应的理论余额以及对方签名确认的所述保费担保资源在所属更新版本下对应的理论余额。

6.根据权利要求5所述的方法，其特征在于，所述客户方数据账本中的任意目标更新版本的记账条目是所述客户方确认满足以下条件时所生成的：

所述服务方签名确认的所述目标投保数据对应所述目标更新版本的摘要信息与所述客户方向所述服务方请求存储的所述目标更新版本下的所述目标投保数据相匹配；和/或，所述服务方签名确认的所述保费担保资源在目标更新版本下对应的理论余额与所述客户方确定的所述保费担保资源在目标更新版本下对应的理论余额相匹配；

所述服务方数据账本中的任意目标更新版本的记账条目是所述服务方确认满足以下条件时所生成的：

所述服务方签名确认的所述目标投保数据对应所述目标更新版本的摘要信息与所述客户方存储的所述目标更新版本下的所述目标投保数据相匹配；和/或，所述服务方签名确认的所述保费担保资源在目标更新版本下对应的理论余额与所述客户方确定的所述保费担保资源在目标更新版本下对应的理论余额相匹配。

7.根据权利要求6所述的方法，其特征在于，所述客户方和所述服务方针对不同更新版本的所述目标投保数据配置有专属的用于签名确认的临时私钥，且所述客户方和所述服务方中的一方在生成新的更新版本的所述目标投保数据后，将上一更新版本用于签名确认的临时私钥公开给另一方以表示作废；

其中，所述服务方数据账本中的非初始更新版本的记账条目还记录有所述客户方在上一更新版本用于签名确认的临时私钥；所述客户方数据账本中的非初始更新版本的记账条目还记录有所述服务方在上一更新版本用于签名确认的临时私钥。

8.一种基于区块链的数据存储保险装置，其特征在于，应用于区块链中的任意节点设备，所述区块链部署有针对目标投保数据设置的保险智能合约，所述装置包括：

接收模块，用于接收服务方提供的目标投保数据和对应的服务方数据账本，以及客户方提供的所述目标投保数据的客户方数据账本；其中，所述服务方数据账本和所述客户方数据账本包含有所述目标投保数据在每个更新版本对应的记账条目；所述服务方数据账本中的每个更新版本的第一目标记账条目记录有所述服务方提供的目标投保数据所属更新版本的摘要信息以及所述客户方签名确认的所述目标投保数据所属更新版本摘要信息；所述客户方数据账本中的每个更新版本的第二目标记账条目记录有所述客户方提供的目标投保数据所属更新版本的摘要信息以及所述服务方签名确认的所述目标投保数据对应所属更新版本摘要信息；

匹配模块，用于调用所述区块链的预言机以执行：将所述服务方提供的所述目标投保数据，与所述服务方数据账本和所述客户方数据账本中的记账条目进行匹配，得到记账条目的匹配结果；

结算模块，用于调用所述保险智能合约以执行：基于所述记账条目的匹配结果确定保险结算清单，并向区块链提交执行所述保险结算清单的区块链交易；其中，所述保险结算清单包括所述客户方向所述服务方支付的保费资源和/或所述服务方向所述客户方支付的理赔资源。

9.一种电子设备，其特征在于，所述设备包括：

处理器；以及，被配置为存储计算机可执行指令的存储器，所述计算机可执行指令在被执行时使所述处理器执行如权利要求1-7任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质用于存储计算机可执行指令，所述计算机可执行指令在被处理器执行时实现如权利要求1-7任一项所述的方法。

Images