一种联盟链上共识失效的应急方法与流程

1.本发明涉及区块链技术领域，尤其涉及一种联盟链上共识失效的应急方法。


背景技术：

2.联盟链是介于公有链与私有链之间的一种系统形态，往往是由多个中心控制，由若干组织一起合作维护一条区块链，该区块链的使用必须是带有权限的限制访问，相关信息会得到保护，如供应链机构或银行联盟。联盟链由组织制定的多个节点控制，这些节点之间根据共识机制对整个系统进行管理与送作；联盟链的各个节点通常有对应的实体机构，只有得到联盟的批准才能加入或退出系统。各个利益相关的机构组织在区块链上展开紧密地合作，并共同维护系统健康稳定的发展
3.联盟链在国内广泛应用，但受限于物理设备原因，多数机构将联盟链部署于一个或者两个机房内，原有的区块链分布式特性受到抑制，部署在一个机房无法形成灾备系统；部署在两个机房内，一旦某个机房整体出现故障，现有的大多数共识将无法正常工作，例如联盟链中常见的raft、pbft、pos等共识，其需要在现有的系统上研发新的应急方法；联盟链部署在两个机房内时，即为常见的双中心部署。一种常见的应急方法，就会在对方中心备份本中心所有节点的信息。单中心故障时，在另一中心启动灾备预案应急，在本地利用备份信息重建区块链节点，恢复现有的网络共识。但是重建区块链节点需要完全克隆源节点，包括复制区块链数据等，极大的耗费存储资源，也影响了网络恢复的效率。


技术实现要素：

4.本发明的目的在于提供一种联盟链上共识失效的应急方法，从而解决现有技术中存在的前述问题。
5.为了实现上述目的，本发明采用的技术方案如下：
6.一种联盟链上共识失效的应急方法，包括以下步骤：
7.s1、在联盟链系统中将共识流程和业务流程进行区分，分别声明共识公钥和业务公钥，并对应设置共识私钥和业务私钥；
8.s2、将所述共识私钥分别部署于两个不同的服务器中心，并且每一个服务器中心中均设置一个备份节点，在所述备份节点中备份存储有另一服务器中心的部分共识私钥，令每一个所述服务器中心均部署有可以满足共识需求的所述共识私钥；
9.s3、在上述联盟链系统运行过程中，当管理员判断所述联盟链网络中出现异常时，并找出出现故障的服务器中心，将出现故障的服务器中心称为故障中心，正常运行的服务器中心称为正常中心；
10.s4、由所述正常中心的所述备份节点备份存储的所述共识私钥模拟计算所述故障节点需要产生的数据，同时由所述正常中心的原共识私钥产生相应的数据；将所述正常中心得到的所有数据发送至对应的所述业务流程中；
11.s5、通过所述业务私钥执行数据处理，得到交易业务的原始数据；
12.s6、将步骤s5中得到的原始数据发送至接收方，从而完成联盟链上共识失效的应急措施。
13.优选的，当步骤s1-步骤s2所述的联盟链系统中某一服务器中心出现故障后，应急流程包括以下步骤：
14.s41、由管理员向所述正常中心的所述备份节点发送应急指令；
15.s42、通过所述备份节点中备份存储的所述故障中心的共识私钥模拟所述故障中心对应参与共识的节点，通过备份的共识私钥模拟计算产生相应的数据；同时利用所述正常中心部署的原共识私钥继续故障前的数据计算过程，得到相应的数据；
16.s43、将步骤s42中所述正常中心得到的所有数据发送至对应的所述业务流程中。
17.优选的，每一个所述服务器中心均包括一个以上服务器节点和一个备份节点；每一个所述服务器节点中存储有且仅有一个共识私钥，所述备份节点中备份存储有一个以上的共识私钥。
18.优选的，所述共识公钥和共识私钥只应用于共识流程中，用于验证交易发起方是否能够经过联盟链系统的共识；所述业务公钥和业务私钥只应用于交易业务流程中，判定交易发起方是否合法。
19.本发明的有益效果是：本发明公开了一种联盟链上共识失效的应急方法，将共识私钥和业务私钥进行区分，便于在应急方案中有效控制备份相应私钥的安全边界；将联盟链系统采用双中心部署的方式，并在每一个服务器中心中相互备份对能够服务器中心的部分共识私钥，令每一个服务器中心正常应用的服务器节点和备份节点中存储的共识私钥的数量均可以满足共识需要，从而缩减完全克隆源节点造成的存储和效率负担；本发明设计了轻量级故障节点的恢复方式，不需要重建、拷贝数据，只需要一些简单的密码学计算，避免了拷贝数据的大量延迟消耗，同时也无需占用额外物理资源重建故障节点，使得故障节点可以秒级恢复，并且支撑系统恢复共识。
附图说明
20.图1是联盟链上共识失效的应急方法流程图；
21.图2是出现故障后应急处理流程图；
22.图3是pbft协议流程图。
具体实施方式
23.为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施方式仅仅用以解释本发明，并不用于限定本发明。
24.一种联盟链上共识失效的应急方法，将联盟链中的共识流程和业务流程进行区分，声明共识公钥和业务公钥；并将共识私钥部署于两个服务器中心中，并在每一个服务器中心中备份对方服务器中心的部分共识私钥，令一个服务器中心中存储的共识私钥可以满足共识要求；当一个服务器中心出现故障时，没有出现故障的服务器中心独立完成共识识别，并将共识私钥处理后的数据传输至相应的业务流程中，通过业务私钥完成数据处理。具体如图1所示，包括以下步骤：
25.s1、在联盟链系统中将共识流程和业务流程进行区分，分别声明共识公钥和业务公钥，并对应设置共识私钥和业务私钥；所述共识公钥和共识私钥只应用于共识流程中，用于验证交易发起方是否能够经过联盟链系统的共识，所述业务公钥和业务私钥只应用于交易业务流程中，判定交易发起方是否合法；
26.s2、将所述共识私钥分别部署于两个不同的服务器中心，并且每一个服务器中心中均设置一个备份节点，在所述备份节点中备份存储有另一服务器中心的部分共识私钥，令每一个所述服务器中心均部署有可以满足共识需求的所述共识私钥；
27.例如，若所述联盟链系统达成共识遵循大多数原则，则每一个所述服务器中心的节点保存的共识私钥的数量应该超过半数；若所述联盟链系统达成共识遵循拜占庭容错原则，则每一个所述服务器中心的节点保存的共识私钥的数量应该超过总数的2/3。具体的若联盟链系统应用pbft共识机制，两个服务器中心中各有15个节点，共30个节点，共识需要超过2/3节点正常工作，即至少需要21个节点正常工作，因此需要每一个服务器中心备份对方服务器中心中的6个节点，才可以满足共识要求。
28.s3、在上述联盟链系统运行过程中，当管理员判断所述联盟链网络中出现异常时，并找出出现故障的服务器中心，将出现故障的服务器中心称为故障中心，正常运行的服务器中心称为正常中心；
29.s4、由所述正常中心的所述备份节点备份存储的所述共识私钥模拟计算所述故障节点需要产生的数据，同时由所述正常中心的原共识私钥继续进行相应的数据计算，得到相应的数据；
30.其中当步骤s1-步骤s2所述的联盟链系统中某一服务器中心出现故障后的应急方法如图2所示，包括以下步骤：
31.s41、由管理员向所述正常中心的所述备份节点发送应急指令；
32.s42、通过所述备份节点中备份存储的所述故障中心的共识私钥模拟所述故障中心，通过备份的共识私钥模拟计算产生相应的数据；同时利用所述正常中心部署的原共识私钥继续计算机故障前的数据计算过程，得到相应的数据；
33.s43、将步骤s42中通过所述共识私钥得到的所有数据发送至对应的所述业务流程中；
34.s5、通过所述业务私钥执行数据处理，得到交易业务的原始数据；
35.s6、将步骤s5中得到的原始数据发送至接收方，从而完成联盟链上共识失效的应急措施。
36.实施例1、联盟链系统中应用raft共识机制
37.联盟链系统中raft共识机制正常工作时，通过所述raft共识机制选取新的领导者节点的工作流程包括以下步骤：
38.i-1)在每一个服务器中心存储有共识私钥的服务器节点中增加本地的currentterm值，并将所述服务器节点切换为候选状态；
39.i-2)所述服务器节点通过各自存储的所述共识私钥进行数据处理，所述共识私钥分别生成一个领导者投票信息；
40.i-3)存储有所述共识私钥的服务器节点将所述领导者投票信息投给自己，并向其他服务器节点发送名为requestvote的rpc消息，请求投票；
41.i-4)所述服务器节点等待其他服务器节点的消息。
42.而所述联盟链系统不能正常生产区块，并且共识不能选举领导者时，所述raft共识机制失效，此时的选取领导者节点的应急流程包括以下步骤：
43.i-1)确认故障中心，并向正常中心的备份节点发送应急指令；
44.i-2)在正常中心的每一个节点中增加本地的currentterm值，并将每一个节点切换为候选状态；
45.i-3)所述正常中心的所有节点通过所述共识私钥进行数据处理，利用存储的所述共识私钥各自生成一个领导者投票信息；
46.i-4)每一个所述共识私钥将所述领导者投票信息投给本身所存储的服务器节点，并将备份节点中备份的共识私钥的票投给本身所存储的服务器节点，并向所述正常中心的其他服务器节点发送名为requestvote的rpc消息，请求投票；i-5)所述服务器节点等待其他服务器节点的消息。
47.从上述遵照raft共识机制的联盟链系统的工作流程可以看到，当有一个服务器中心出现故障时，联盟链系统中由于有半数或者以上的服务器节点不能参与共识流程，所以不能正常选举领导者节点；针对此种情况，利用正常中心中备份的共识私钥，即可以使参与共识流程的共识私钥的数量满足共识需求，且该共识结果等同于所有节点均参与共识的共识，从而恢复raft协议，达成应急目标。
48.实施例2、联盟链系统中应用pbft共识机制如图3所示
49.联盟链系统中pbft共识机制正常工作时，通过所述pbft共识机制的共识流程包括以下步骤：
50.i-1)pre-prepare阶段：主节点负责验证请求消息，并产生相应的pre-prepare消息，然后将pre-prepare消息广播给所有参与共识的节点，节点收到pre-prepare消息之后，验证pre-prepare消息的合法性并广播对应的prepare消息；
51.i-2)prepare阶段：节点收集prepare消息，收集满2f 1的prepare消息后，开始广播commit消息；
52.i-3)commit阶段：负责收集commit消息，某节点收集满2f 1的commit消息后，直接将本地缓存的原始请求消息进行处理并对更改相应的系统状态，即完成共识。
53.而prepare消息收集数量不足时，所述pbft共识机制失效，此时的选取领导者节点的应急流程包括以下步骤：
54.i-1)确认故障中心，并向正常中心的备份节点发送应急指令；
55.i-2)pre-prepare阶段：主节点负责验证请求消息，并产生相应的pre-prepare消息，然后将pre-prepare消息广播给正常中心的服务器节点和备份节点，节点收到pre-prepare消息之后，验证pre-prepare消息的合法性；在正常中心的服务器节点，利用其存储的共识私钥生成对应的prepare消息；在正常中心的备份节点，利用备份的共识私钥生成对应的prepare消息，广播所述正常中心产生的所有prepare消息；
56.i-2)prepare阶段：节点收集prepare消息，收集满2f 1的prepare消息后，利用所述正常中心的所有共识私钥生成对应的commit消息，所述commit消息包括所述正常中心的原始服务器节点的共识私钥生成的对应的commit消息，还包括所述正常中心的备份节点中备份的共识私钥生成的对应的prepare消息，开始广播所述commit消息；；
57.i-3)commit阶段：负责收集所述commit消息，某节点收集满2f 1的commit消息后，直接将本地缓存的原始请求消息进行处理并更改相应的系统状态，从而完成共识。
58.从上述遵照pbft共识机制的联盟链系统的工作流程可以看到，当有一个服务器中心出现故障时，联盟链系统中由于有半数或者以上的服务器节点不能参与共识流程，所以不能产生数量足够的prepare消息和commit消息；针对此种情况，利用正常中心中备份的共识私钥，使联盟链系统中参与共识流程的共识私钥的数量满足共识需求，产生足够数量的prepare消息和commit消息，从而恢复pbft协议，达成应急目标。
59.通过采用本发明公开的上述技术方案，得到了如下有益的效果：
60.本发明公开了一种联盟链上共识失效的应急方法，将共识私钥和业务私钥进行区分，便于在应急方案中有效控制备份相应私钥的安全边界；将联盟链系统采用双中心部署的方式，并在每一个服务器中心中相互备份对能够服务器中心的部分共识私钥，令每一个服务器中心正常应用的服务器节点和备份节点中存储的共识私钥的数量均可以满足共识需要，从而缩减完全克隆源节点造成的存储和效率负担；本发明设计了轻量级故障节点的恢复方式，不需要重建、拷贝数据，只需要一些简单的密码学计算，避免了拷贝数据的大量延迟消耗，同时也无需占用额外物理资源重建故障节点，使得故障节点可以秒级恢复，并且支撑系统恢复共识。
61.以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视本发明的保护范围。