CN113409154A

CN113409154A - 一种基于可信存储的安责险处理方法和系统

Info

Publication number: CN113409154A
Application number: CN202110504241.XA
Authority: CN
Inventors: 朱晓宁; 李园园; 侯鹏程
Original assignee: Jingying Digital Technology Co Ltd
Current assignee: Jingying Digital Technology Co Ltd
Priority date: 2021-05-10
Filing date: 2021-05-10
Publication date: 2021-09-17

Abstract

本申请涉及一种基于可信存储的安责险处理方法和系统，所述方法包括：将保单信息转换为智能合约并发布到区块链网络；在接收到投保信息后，对所述投保信息进行加密，通过加密后的信息构建环机密事务，并将所述环机密事务记录在对应的智能合约上；银行节点通过自身的私钥解密所述账户信息，并进行支付保费操作和/或划拨理赔金操作；医疗机构节点通过自身的私钥解密所述身份信息，并将与所述身份信息相匹配的医疗信息录入合约。本申请的方案使用环机密事务进行加密，可以很好地保护事务双方的隐私信息，银行只能获取用户的账户信息，医疗机构只能获取用户的身份信息，任何节点都无法获取与自身业务无关的信息。

Description

一种基于可信存储的安责险处理方法和系统

技术领域

本申请涉及区块链技术领域，具体涉及一种基于可信存储的安责险处理方法和系统。

背景技术

安全生产责任保险(以下简称安责险)，是指保险机构对投保的生产经营单位发生的生产安全事故造成的人员伤亡和有关经济损失等予以赔偿，并且为投保的生产经营单位提供事故预防服务的商业保险。安全生产责任保险是生产经营单位在发生生产安全事故以后对死亡、伤残者履行赔偿责任的保险。对于煤矿企业等高危行业，伤亡事故时有发生，安责险有助于加强和改善安全生产管理。

相关技术中，目前传统的安责险中投保与理赔流程过于繁琐，需要提交大量证明资料。容易出现医疗机构提供的文件与保险公司所需文件不匹配的情况，人工审核文件也容易出现出错与遗漏。这些问题都会导致整个理赔周期耗时较久，效率低下。另一方面，由于缺乏有效的监管手段，保险公司可能隐瞒有关保险内容的真实情况，诱使客户投保；投保人可能故意制造或捏造保险事故以谋取赔偿金。再者，由于在区块链上存储的数据对于所有参与方公开，这触及到用户的隐私保护问题。

发明内容

为至少在一定程度上克服相关技术中存在的问题，本申请提供一种基于可信存储的安责险处理方法和系统。

根据本申请实施例的第一方面，提供一种基于可信存储的安责险处理方法，包括：

将保单信息转换为智能合约并发布到区块链网络；

在接收到投保信息后，对所述投保信息进行加密，通过加密后的信息构建环机密事务，并将所述环机密事务记录在对应的智能合约上；所述投保信息至少包括身份信息和账户信息；

银行节点通过自身的私钥解密所述账户信息，并进行支付保费操作和/或划拨理赔金操作；

医疗机构节点通过自身的私钥解密所述身份信息，并将与所述身份信息相匹配的医疗信息录入合约。

进一步地，所述构建环机密事务，包括：

选取一组随机数，根据选取的随机数计算初始隐藏参数；

根据所述初始隐藏参数和各节点的公钥计算各节点对应的隐藏参数；

根据实际签名的用户的私钥计算最终隐藏参数；

根据多个隐藏参数生成签名，并将签名和消息一同发送到第三方节点进行验证。

进一步地，所述计算初始隐藏参数，包括：

选择随机数t_j，其中j∈1,2,…,k；

计算

并计算

其中，G是椭圆曲线循环群上的生成元，每个用户P_i都拥有k对公私钥，i＝1,2,…,n；P_π是实际签名的用户；Hash()为哈希函数；m为用户需要签名的消息。

进一步地，所述计算各节点对应的隐藏参数，包括：

对于i＝π+1,π+2,…,n,1,2,…,π-1，为用户P_i选择随机数

并计算

其中j∈1,2,…,k；

计算

并根据c_i+1计算

其中，

为公钥。

进一步地，所述根据实际签名的用户的私钥计算最终隐藏参数，包括：

根据实际签名的用户的私钥x_π计算

相应地，所述根据多个隐藏参数生成签名，包括：

生成签名

进一步地，所述方法还包括：

第三方节点接收到消息后，使用签名σ中提供的变量进行验证；

对于i＝1,…,n，从i＝1开始依次计算

和c_i；

计算到最后一个用户的c_n+1，判断c_n+1是否等于c₁；

如果相等，证明签名合法；如果不相等，则签名无效。

进一步地，所述区块链网络的节点至少包括：用户、保险公司、医疗机构、银行；节点之间通过P2P协议进行通信。

节点之间消息共识的步骤包括：

客户端向主节点发送请求，激活主节点的服务操作；

主节点给请求赋值一个序列号，广播序列号分配消息和客户端的请求消息，并构造pre-prepare消息发送给各个节点；

从节点接受prepare消息，向其他服务节点广播prepare消息；

各节点对试图内的请求和次序进行验证后，广播Commit消息，执行收到的客户端请求并给客户端以响应；

客户端等待来自不同节点的响应，若相同的响应数量大于预设阈值，则该响应为运算的结果。

进一步地，新增节点的步骤包括：

新增节点通过读取配置文件信息，主动向现有节点发起连接，确认所有节点连接成功后，更新自己的路由表，并发起recovery消息；

网络中的其他节点接收到新增节点的连接请求后确认同意该节点加入，然后向全网广播AddNode消息；

当现有节点收到R条AddNode消息后，更新自身的路由表，随后开始回应新增节点的共识消息请求；

新增节点完成recovery之后，向全网现有节点广播Ready请求；

现有节点在收到Ready请求后，重新计算新增节点加入之后的节点个数信息，随后将其封装到AgreeUpdate消息中，进行全网广播；

新增节点加入后的共识网络产生一个新的主节点，该主节点在收到2f+1个AgreeUpdate消息后，以新的主节点的身份发送Update消息；

全网所有节点在收到Update消息之后确认消息的正确性，进行路由表的更新；

每个节点完成路由表更新后，全网广播FinishUpdate消息；

节点在收到2f+1个FinishUpdate消息后，处理后续请求，完成新增节点流程。

根据本申请实施例的第二方面，提供一种基于可信存储的安责险处理系统，包括：

保单注册模块，用于将保单信息转换为智能合约并发布到区块链网络；

投保模块，用于在接收到投保信息后，对所述投保信息进行加密，通过加密后的信息构建环机密事务，并将所述环机密事务记录在对应的智能合约上；所述投保信息至少包括身份信息和账户信息；

银行节点，用于通过自身的私钥解密所述账户信息，并进行支付保费操作和/或划拨理赔金操作；

医疗机构节点，用于通过自身的私钥解密所述身份信息，并将与所述身份信息相匹配的医疗信息录入合约。

根据本申请实施例的第三方面，提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上任意一种实施例所述方法的操作步骤。

本申请的实施例提供的技术方案具备以下有益效果：

本申请的方案使用环机密事务进行加密，可以很好地保护事务双方的隐私信息，银行只能获取用户的账户信息，医疗机构只能获取用户的身份信息，任何节点都无法获取与自身业务无关的信息；业务过程中生成的各种信息都被记录在区块链中，其它节点通过共识算法同步记录信息，这使得智能合约内容无法被篡改。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1是根据一示例性实施例示出的一种基于可信存储的安责险处理方法的流程图。

图2是区块链中节点的组织结构示意图。

图3是区块结构示意图。

图4是环机密事务构造流程示意图。

图5是根据一示例性实施例示出的一种安责险处理方法的流程示意图。

图6是根据一示例性实施例示出的一种安责险处理系统的结构示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的方法和装置的例子。

图1是根据一示例性实施例示出的一种基于可信存储的安责险处理方法的流程图。该方法可以包括以下步骤：

步骤S1：将保单信息转换为智能合约并发布到区块链网络；

步骤S2：在接收到投保信息后，对所述投保信息进行加密，通过加密后的信息构建环机密事务，并将所述环机密事务记录在对应的智能合约上；所述投保信息至少包括身份信息和账户信息；

步骤S3：银行节点通过自身的私钥解密所述账户信息，并进行支付保费操作和/或划拨理赔金操作；

步骤S4：医疗机构节点通过自身的私钥解密所述身份信息，并将与所述身份信息相匹配的医疗信息录入合约。

该实例中的安责险平台基于联盟链，可以由政府相关部门作为该联盟链的准入机构。当有新的联盟链成员加入时，通过准入机构进行审核。审核通过后，为该成员颁发基于该联盟链的机构证书。当参与方节点之间进行通信时，使用证书中的公钥作为身份标识。若所述节点标识通过，则确认为该联盟链中的成员。该实例中，通过准入节点注册为联盟链成员节点的有：用户、保险公司、医疗机构、银行。

应当理解的是，虽然图1的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图1中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

本发明基于区块链的去中心化存储、智能合约与隐私保护算法，提出一种安全可信的区块链安责险处理方法。为进一步详述本申请的技术方案，首先对区块链相关技术进行说明。

本发明是由多个节点通过网络通信的形式形成的分布式系统实现的，系统中节点的组织结构如图2所示。节点之间通过P2P协议进行通信，P2P协议是运行在TCP协议之上的应用层协议。在分布式系统中，任何终端都可以加入网络成为节点。节点的功能包括：路由，用于支持节点间的通信；应用，根据实际的应用需求提供特定的服务。

图3给出了区块链中的区块结构示意图。区块按照时间先后顺序排列，每个区块中包含时间戳、上一个区块的哈希值、本区块的哈希值，区块中的交易以Merkle树的形式存储，每个区块通过存储上一个区块的哈希值彼此相连，形成链状结构。区块链本质上是一种去中心化的存储结构，通过密码学、共识算法等技术保证数据的公开、透明、可追溯、不可伪造。

以区块链中的节点为例，节点可以将本地的当前交易发送给区块链系统中的其他节点，其他节点验证成功后，将交易记录存入各自本地的区块链账本中。区块链系统通过共识算法保证各个节点账本的正确性和一致性。为了支持联盟中新成员的加入和退出，需要通过共识实现动态的节点增加或删除，该实例中使用高鲁棒性拜占庭容错算法(RobustByzantine Tolerance，简称RBFT)实现。假设系统的总节点数为|R|＝3f+1，RBFT算法可以容忍无效或者恶意节点数为f，需要有2f+1个正常节点。也就是说，RBFT算法可以容忍小于1/3个无效或者恶意节点。RBFT是一种状态机副本复制算法，所有的副本在一个视图轮换的过程中操作，主节点通过视图编号以及节点数集合来确定，即主节点p＝v mod|R|，其中v是视图编号，|R|是节点个数，p是主节点编号。RBFT算法每个客户端请求需要经过5个阶段，通过采用两次两两交互的方式在服务器达成一致后再执行客户端的请求。由于客户端不能从服务端获得任何服务器运行状态，RBFT中主节点是否发生错误只能由服务器监测。如果服务器在一段时间内不能完成客户端的请求，就会触发视图更换协议。

协议中消息共识的过程如下：

1.客户端向主节点发送请求，激活主节点的服务操作；

2.主节点给请求赋值一个序列号n，广播序列号分配消息和客户端的请求消息m，并将构造pre-prepare消息发送给各个节点；

3.从节点接受prepare消息，向其他服务节点广播prepare消息；

4.各节点对试图内的请求和次序进行验证后，广播Commit消息，执行收到的客户端请求并给客户端以响应；

5.客户端等待来自不同节点的响应，若有f+1个响应相同，则该响应为运算的结果。

协议中新增节点的过程如下：

1.新增节点通过读取配置文件信息，主动向现有节点发起连接，确认所有节点连接成功后，更新自己的路由表，并发起recovery消息；

2.网络中的其他节点接收到新增节点的连接请求后确认同意该节点加入，然后向全网广播AddNode消息，表明自己同意该新节点加入整个共识网络；

3.当现有节点收到|R|条AddNode消息后，更新自身的路由表，随后开始回应新增节点的共识消息请求(在此之前，新增节点的所有共识消息是不予处理的)；

4.新增节点完成recovery之后，向全网现有节点广播Ready请求；

5.现有节点在收到Ready请求后，重新计算新增节点加入之后的|R|,p等信息，随后将其封装到AgreeUpdate消息中，进行全网广播；

6.新增节点加入后的共识网络会产生一个新的主节点，该主节点在收到2f+1个AgreeUpdate消息后，以新的主节点的身份发送Update消息；

7.全网所有节点在收到Update消息之后确认消息的正确性，进行路由表的更新；

8.每个节点完成路由表更新后，全网广播FinishUpdate消息；

9.节点在收到2f+1个FinishUpdate消息后，处理后续请求，完成新增节点流程。

动态地增加联盟成员不影响正常的业务进行，在保证系统高鲁棒性的前提下又提供了可扩展性。

智能合约是部署在区块链账本上的代码，在满足一定条件时会自动执行，根据实际的业务需求用于完成自动化的交易。例如保险合约，可以通过检验保险对象的凭证，自动执行理赔操作。节点创建智能合约时，发布一个0地址交易到区块链系统，用以代表创建合约的命令。系统返回一个智能合约账户的地址，在该账户下存储着合约代码及合约内的变量。节点调用合约时，输入合约内包含的函数及相关参数，作为交易的内容发送到合约对应的账户地址。系统解析交易内的函数操作并执行合约内对应函数的代码，修改合约内的变量值。

当保险公司要发布新的保险时，保险公司以准入机构发布的身份将保单文件将录入智能合约，并广播到联盟链网络中。进一步的，保险公司节点通过转换模块将保单中的规则条例、身份标识、保险价格、触发条件、赔付金额等信息转换为智能合约中的语言。保单中的规则条例在转换为智能合约中的规则后应包含：规则名称、规则满足的条件以及满足条件后执行的代码。其他节点接收到新合约后检查保险公司的身份信息是否正确；合约中的规则是否和原始保单中的规则相对应。检查通过后，加入到本地的区块链中，更新区块链账本信息。存储该合约所在地址，用于之后的操作中再次调用。所有参与者节点可以实时追踪查看合约的当前状态。

用户可以线上查询已经发布的保险单，并在线进行投保。用户在进行投保时，需要将自己的身份信息(如身份证号、姓名等)用医疗机构的公钥加密，并将自己的账户信息用银行的公钥加密，再通过加密后的信息构建环机密事务。然后调用保险合约，使用保险合约中的注册方法注册投保信息，将环机密事务录入合约。变动的合约生效后，银行节点解密用户的账户信息，并从用户账户向保险公司账户发送投保费。对于合约中存储的用户账户信息的密文，仅有用户和银行双方知晓其对应明文。

当投保后的用户需要医疗机构开具证明用于理赔时，医疗机构首先解密用户身份信息的密文，然后核实用户身份信息是否与保险合约中的身份信息相同。如果相同，则调用保险合约中的存证方法，将该用户的医疗证明录入合约，所发送的证明的格式需符合合约中相关规则所需要的证明格式，且内容上满足该规则需要满足的条件。由于使用环机密事务加密了合约中的用户信息，仅有用户和医疗机构双方知晓其内容。

在达成触发条件所需的所有规则时，合约会自动向银行节点发送赔偿请求，银行节点解密用户的账户信息，并从保险公司账户向用户账户发送赔偿金。

该实例中使用环机密事务(Ring Confidential Transactions，简称RCT)对用户的隐私信息进行加密。环机密事务可以理解为，事务的发送方在对事务签名前，临时将网络中的其他人组成一个“群”。发送方使用自己的私钥和群中所有人的公钥，对交易的信息进行签名。通过这种方法，即使第三方拿到了这个群里所有人的公钥，也只能知道该事务出自这个群中的某个人，而无法对应到具体的人。由于储存于区块链中的数据都是对外公开的，没办法通过设置权限的方式限制查看，所以使用环机密事务加密可以很好地保护事务双方的隐私信息。

本实例中的隐私保护方法涉及公钥加密与数字签名。其中，公钥加密是指使用一对公共密钥(简称公钥)与私有密钥(简称私钥)，这两个密钥是数学相关，其中公钥是对外公开的，而私钥是用户私有的。用公钥加密后所得的信息，只能用相应的私钥才能解密。数字签名是指用户用自己的私钥对信息生成一段无法伪造的数字串，其他人可以使用对应的公钥来识别这段数字串，从而辨别信息是否被篡改或者伪造。本实例中的加密方法是基于椭圆曲线的加密体系(Elliptic curve cryptography，简称ECC)，考虑到区块链存储能力的限制，使用基于ECC的公钥加密和数字签名可以在保证安全程度的前提下提供更快的加密速度与密文体积。

本实例中的环机密事务流程如图4所示，设G是安全系数为λ,阶为q的椭圆曲线循环群上的生成元。每个用户P_i(i＝1,2,…,n)都拥有k对公私钥，其中

为私钥(j＝1,2,…,k)，

为公钥。假设m为用户需要签名的消息，P_π是实际签名的用户，其中H_p是一个哈希算法，它的输入和输出都是椭圆曲线上的点。构造事务的步骤如下：

1.选择随机数t_j(其中j∈1,2,…,k)计算

并计算

这两个变量用于参与下面构建环的操作。

2.对于其他用于隐藏真实用户信息的掩藏账户(这里用下角标i＝π+1,π+2,…,n,1,2,…,π-1表示他们在环中的对应位置)，为他们选择随机数

并计算

这里c_i称为致盲因子，用于隐藏

的值，由于实际操作中

的取值范围有限，使得攻击者可以通过穷举的方法猜出它的值，所以需要使用c_i来防止穷举攻击。下一步再计算

用于下一个掩藏账户中

的计算，直到第π-1个掩藏账户为止。

3.用户使用自己的私钥x_π计算

最终使环闭合。在第三方看来，环中每一个账户的

都是通过前一个账户通过

计算出的，无法分辨哪个才是实际签名的账户。

4.生成签名

并连同消息m发送到第三方节点进行验证。

第三方节点接收到消息后，使用签名中提供的变量，对于账户i＝1,…,n,从i＝1开始依次计算

和c_i直到计算到最后一个账户的c_n+1，然后判断c_n+1是否等于c₁，如果相等，证明签名合法；如果不相等，则签名无效。从验证者的视角看来，每一个账户的计算过程相同，无法分辨真实用户与掩藏用户。

更加具体地，本申请的环机密事务还具有以下特点。

1、在CryptoNote(基于环签名和一次性密钥)的基础上再实现：

(1.1)隐藏交易金额。通过将Confifidential Transactions加入环签名实现：

C_in,i＝x_iG+a_iH，i＝1,2...

C_out,j＝y_jG+b_jH，j＝1,2...

∑_icin-∑_jcout＝zG；

用(z,zG)进行环签名，如果签名验证正确，即证明∑_ia＝∑_jb。

(1.2)防止两次花费。通过链接“key-image”实现：

I＝x_jHp(P_j)，j∈{1,2...}；

在签名的链接阶段，将相同的I进行链接，第二次签名作废，避免用同一个密钥对进行两次环签名，即：每个密钥对只允许签名一次，从而避免了重复花费。

2、LSAG(Back)

2.1、GEN：

(2.1.1)找n个随机公钥序列：P_i,i＝0,1,...,n，代表环签名的n个用户。

(2.1.2)选定私密序号j，j∈{1,2...n}，设置p_j＝x_jG,其中(x_j,P_j)是真正的签名密钥对。

(2.1.3)计算“key-image”：I＝x_jHp(P_j)。

2.2、SIGN：

(2.2.1)设α、s_i i＝1,2,3...n且i≠j，计算：

L_j＝αG

R_j＝αHp(P_j)

c_j+1＝Hs(m,L_j,R_j)

(2.2.2)计算：

L_j+1＝s_j+1G+c_j+1P_j+1

R_j+1＝s_j+1Hp(P_j+1)+c_j+1I

c_j+2＝Hs(m,L_j+1,R_j+1)

一直计算到L_j-1、R_j-1、c_j：(mod n)

L_j-1＝s_j-1G+c_j-1P_j-1

R_j-1＝s_j-1Hp(P_j-1)+c_j-1I

c_j＝Hs(m,L_j-1,R_j-1)

(2.2.3)把：L_j＝αG

R_j＝αHp(P_j)

化成：L_j＝s_jG+c_j-1P_j

R_j＝s_jHp(P_j)+c_jI的形式，

令s_j＝α-c_jx_j、α＝s_j+c_jx_j即可。从而形成环。

(2.2.4)签名：σ＝(I,c₁,s₁,...,s_n)。

2.3、VER：计算L_i、R_i、c_i，

并检验c_n+1＝c₁、c_i+1＝Hs(m,L_i,R_i)，其中i＝1,2...n。

2.4、LINK：检测是否有相同的I。如果有，则拒绝签名。

3、MLSAG(对LSAG的推广)

3.1、GEN：

签名矩阵：P_i ^j，i＝1,2...n、j＝1,2...m；选定私密序号π，

π∈{1,2...n}，代表真实的签名行号。密钥对记为(x_π ^j,P_π ^j),

计算“key-image”：I＝x_π ^jHp(P_π ^j)，j＝1,2...m。

3.2、SIGN：

设α_π ^j、s_i ^j i＝1,2,3...n且i≠j，j＝1,2...m。计算：

L_π ^j＝α_π ^jG；R_π ^j＝α_π ^jHp(P_π ^j)，j＝1,2...m；

c_π+1＝Hs(m,L_π ¹,R_π ¹...L_π ^m,R_π ^m)

计算：

L_π+1 ^j＝s_π+1 ^jG+c_π+1P_π+1 ^j

R_π+1 ^j＝s_π+1 ^jHp(P_π+1 ^j)+c_π+1I_j，j＝1,2...m；

c_π+2＝Hs(m,L_π+1 ¹,R_π+1 ¹...L_π+1 ^m,R_π+1 ^m)

一直计算到L_π-1 ^j、R_π-1 ^j、c_π-1：(mod n)

L_π-1 ^j＝s_π-1 ^jG+c_π-1P_π-1 ^j

R_π-1 ^j＝s_π-1 ^jHp(P_π-1 ^j)+c_π-1I_j，j＝1,2...m；

c_π＝Hs(m,L_π-1 ¹,R_π-1 ¹...L_π-1 ^m,R_π-1 ^m)；

把：L_π ^j＝α_π ^jG，R_π ^j＝α_π ^jHp(P_π ^j)，j＝1,2...m；

化成：L_π ^j＝s_π ^jG+c_πP_π ^j，R_π ^j＝s_π ^jHp(P_π ^j)+c_πI_j，j＝1,2...m的形式；

令s_π ^j＝α_π ^j-c_π ^jx_π ^j、α_π ^j＝s_π ^j+c_π ^jx_π ^j即可。从而形成环。

签名：σ＝(I₁...I_m,c₁,s₁ ¹...s₁ ^m...s_n ¹...s_n ^m)。

3.3、VER：计算L_i ^j、R_i ^j、c_i，并检验c_n+1＝c₁、c_i+1＝Hs(m,L_i ¹,R_i ¹...L_i ^m,R_i ^m)，其中i＝1,2...n；j＝1,2...m。

3.4、LINK：检测是否有相同的I_j。如果有，则拒绝签名。

4、Ring CT For Monero Protocol

4.1、Transaction Generation

(4.1.1)设{(P_i ^j,C_i ^j)}，(i＝1,2...n，j＝1,2...m)为公钥/承诺对集合；选定私密序号π，π∈{1,2...n}，P_π ^j对应的私钥是x_π ^j(j＝1,2...m)。即：n个账户进行环签名，其中P_π ^j(j＝1,2...m)为真实转账，且共有m个输入。

(4.1.2)选定集合{(P_i ¹,C¹)...(P_i ^m,C_i ^m)}，i＝1,2...q+1；把真实的转账账户隐藏其中。

(4.1.3)记输出地址和输出值承诺为(Q_i，C_i,cout)i＝1,2...k，即k个输出。

(4.1.4)记签名矩阵：

利用A在消息m上计算MLSAG signature X，其中m是输出集合{(Q_i，C_i,cout)}的哈希值。

4.2、Transaction Verifification：与MLSAG验证步骤相同。

上述基于区块链的安责险处理方法，保险公司可以自发的创建保单内容公布于区块链网络中，用户可以异步地浏览保单与投保。在接受到满足保险内容的相关的证明文件时，智能合约可以自动化的执行理赔流程，投保方可以在达成理赔条件后快速收到来自合约的赔偿。简化了审核流程，不再依赖人工操作，既减少人力的开支，又提高了处理效率。区块链不可篡改与可追溯的特点可以为核实情况提供重要的依据，做到保单信息的透明、安全。且由于使用环机密事务隐私化处理了用户信息，可以保障用户的隐私信息不泄露。

下面结合具体的应用场景，对本申请的方案进行拓展说明。

如图5所示，在一些实例中，提供了一种安全可信的区块链安责险处理方法的流程示意图，包括以下步骤：

1.保险公司通过保单注册模块将保单信息转换为智能合约并发布到区块链网络。

2.所有节点对新合约所在的交易进行验证并记录新合约的信息。

3.用户可以从保单管理模块提供的接口查看保单信息。

4.用户可以选择相应的保单，输入相关信息，投保模块对相关的信息进行加密，构建环机密事务并记录在对应的智能合约上。

5.银行节点在接收到更新后的合约后，用自己的私钥解密用户的账户信息，并从用户账户支付相应的保费给保险公司。银行节点将这些操作的摘要用自己的私钥进行签名，记录到合约上。

6.医疗结构节点用自己的私钥解密用户的身份信息，核实用户的身份与保单上的身份。审核通过后，将用户的医疗信息录入合约，并将这些操作用自己的私钥进行签名，记录到合约上。

7.当合约中的验证模块证明信息满足保险的理赔规则时，合约将自动触发理赔流程，改变为待支付理赔金的状态。

8.银行节点在接收到更新后的合约后，解密用户的账户信息，并将理赔金从保险公司账户支付给相应的用户账户。银行节点将这些操作的摘要用自己的私钥进行签名，记录到合约上。

在该流程中，从智能合约被发布到链上后，参与方节点可以实时追踪查看合约的当前状态，不同的参与方只能解密出和自身业务相关的密文所对应的信息。具体的，对于保险公司，它只知道自己的账户信息；对于用户，他只知道自己的身份信息和账户信息；对于医院，它只知道用户的身份信息；对于银行，它只知道用户和保险公司的账户信息；对于第三方的记账节点，无法从区块链中获取用户的个人信息。以上所述的信息仅包含联盟链系统中的信息，不包含各参与方本身的中心化数据库中存储的信息。

如图6所示，在一些实例中，还提供一种基于可信存储的安责险处理系统，包括：

该系统中的智能合约模块能够接收各个节点发送的消息，并将消息转换为合约中的条例规则并进行上链处理。具体的，可以将保险公司节点的保单转换为保险合约记录到区块链；可以将用户的投保信息记录到所要投保的保险合约中；可以将医疗机构的诊疗证明或就诊凭证记录到保险合约中。可信存储模块提供可信的保险信息、事故信息、理赔信息。公钥加密模块提供对信息的加解密和签名功能。身份管理模块提供用户的身份信息功能。隐私算法模块可以对用户的信息做隐私化处理。联盟准入模块通过共识算法管理新联盟成员的加入。上述实例所描述的平台和各节点间签订保险智能合约的过程，生成的各种信息都被记录在区块链中，其它节点通过共识算法同步记录信息，这使得智能合约内容无法被篡改。

本申请还提供如下实施例：

一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现一种基于可信存储的安责险处理方法，包括：将保单信息转换为智能合约并发布到区块链网络；在接收到投保信息后，对所述投保信息进行加密，通过加密后的信息构建环机密事务，并将所述环机密事务记录在对应的智能合约上；所述投保信息至少包括身份信息和账户信息；银行节点通过自身的私钥解密所述账户信息，并进行支付保费操作和/或划拨理赔金操作；医疗机构节点通过自身的私钥解密所述身份信息，并将与所述身份信息相匹配的医疗信息录入合约。

可以理解的是，上述各实施例中相同或相似部分可以相互参考，在一些实施例中未详细说明的内容可以参见其他实施例中相同或相似的内容。

需要说明的是，在本申请的描述中，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。此外，在本申请的描述中，除非另有说明，“多个”的含义是指至少两个。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。

应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。