基于高鲁棒性拜占庭容错的联盟链数据安全实时上链方法

本发明涉及到联盟链拜占庭容错算法，属于区块链技术领域，具体涉及一种基于高鲁棒性拜占庭容错的联盟链数据安全实时上链方法。

背景技术：

随着互联网在各个行业中的广泛普及，数据的传递、存储的速度和安全性一直受到极大挑战：一方面，数据在传输时容易受到黑客的截取，或者因为网络波动，消息无法传递到目标计算机；另一方面，由于用户量激增，服务器处理数据的速度会受到极大考验，各个服务器之间数据的同步问题也会成为架构方面的考虑因素之一。

区块链的分布式共识网络具有去中心化、防止数据篡改、强依赖密码学的特点。去中心化意味着数据的处理和存储问题不再由某一个机构或组织来完成，而是由多机构，也就是多个网络中的节点共同完成，因此即使某一个网络节点被攻破也不至于数据完全丢失，符合安全性的特点；区块链网络中的每个节点都保存着整个区块链的一个拷贝，并且可以保证所有节点的拷贝相同，因此可以实现多方共识下的数据一致性，防止数据被恶意修改，符合透明开放和状态一致的特点；针对不同业务，可以编写能够自动化执行的智能合约，极大地提高了数据在区块链上交互的灵活性。但是区块链的吞吐量和确认延迟等方面存在瓶颈(比如比特币吞吐量约为平均每秒7笔，交易确认时间约为一小时)。

以实用拜占庭容错算法为代表的确定性算法可以更快地完成共识，提高区块链中数据的上链速度，因此被广泛应用于对吞吐量和延迟要求较高的联盟链系统中。虽然联盟链吞吐量比较高而且延迟低，但节点数量较多时存在通信复杂度高且可扩展性差的问题。目前已经有了对于实用拜占庭容错算法的改进算法，即高鲁棒性拜占庭容错算法。该方法在原有的实用拜占庭容错算法的基础之上，增加了节点加入和节点恢复这两个特性，提高了原实用拜占庭容错算法的鲁棒性。但是在节点数量增多、请求数量剧增时，高鲁棒性拜占庭容错算法性能会下降得很快，预防节点攻击等方面也比较薄弱，难以达到数据安全实时上链的要求。

技术实现要素：

有鉴于此，本发明的目的是提供一种基于高鲁棒性拜占庭容错的联盟链数据安全实时上链方法，该方法能够提升联盟链网络在短时间内处理大量数据上链请求的能力，并且能够在共识网络中节点较多的情景下仍然以较低的延迟实现数据上链，达到实时上链的效果。同时，该方法可以预防恶意节点的拜占庭行为，提升联盟链网络的鲁棒性。

实现本发明目的的具体技术方案是：

一种基于高鲁棒性拜占庭容错的联盟链数据安全实时上链方法，该方法在联盟链网络中使用，网络中所有节点遵循恶意节点监督机制；网络允许动态加入节点，若有新增节点加入，则进入节点动态增加流程，增加后若节点数量超过设定阈值，则启动分区管理与分区共识机制；网络中的每条消息都包含消息内容m、m的摘要d(m)、和发送这条消息的节点对d(m)的签名sig；该方法具体包括以下步骤：

步骤1：请求转发

网络中的任意节点接收客户端的数据上链请求，请求的内容包括：o：需要上链的数据内容、t：客户端的时间戳、c：客户端编号；其中，从节点接收到请求之后转发给主节点，主节点自身也能直接接收请求；

步骤2：预准备阶段

主节点等待一个超时时间或接收到满足最大区块大小数量的数据上链请求，计算出本批次的请求从被接收到被处理的平均时间，如果超过给定阈值，则启动动态视图轮换机制；未超过给定阈值，则首先给该批次的请求分配一个编号n，对接收到的数据上链请求逐个进行正确性校验，剔除非法请求，将请求按照接收的时间顺序打包成块后进行验证，最后将定序好的数据上链请求信息连同验证结果写入预准备消息＜＜pre-prepare,v,n,d>,n>，其中v：视图编号，广播给网络中所有节点；

步骤3：准备阶段

从节点在收到主节点的预准备消息后，首先进行签名正确性校验，如果之前从未收到任何v,n,m相同的预准备消息，检查当前的视图与区块号信息，确认无误则接受该预准备消息，将预准备消息存入缓存，并向其他所有节点广播准备消息；

步骤4：提交阶段

从节点对接收到的准备消息进行签名正确性校验并存入缓存，直至收到超过三分之二的其他节点具有相同的v,n,m的准备消息之后，验证对应编号为n的预准备消息，并将验证结果与主节点写入预准备消息中的验证结果进行比对，验证成功则广播提交消息，否则启动主节点的动态视图轮换；

步骤5：写入账本阶段

从节点在收到超过三分之二的其他节点具有相同的v,n,m的提交消息后，将请求上链的数据写入本地账本，返回客户端数据上链成功消息，此时若网络未分区，则完成数据上链，若网络已分区，则完成数据写入支链。

进一步的，所述恶意节点监督机制：为联盟链网络中每个参与节点设置恶意行为记录值，并初始化为0，如果发现有节点有恶意行为，则将次数加一，如果检测到某个节点的恶意行为次数超过上限，则启动清理程序，将该节点从联盟链网络中删除。

进一步的，所述动态视图轮换机制：分别为两种视图轮换：第一种，当主节点有大量的数据上链任务时，向其他节点发送一条申请使用专用视图消息，从节点收到主节点的消息时，首先检查是否在同一个视图下，再检查请求的完成平均时间是否超过给定阈值，如果在同一视图下并超过阈值则向主节点发送确认消息表示同意；主节点收到了相同视图下的确认消息后，进入专用视图状态，主节点发起快速批量处理机制，达到规定时间阈值后，主节点的专用视图状态结束；第二种，当从节点检测到主节点存在异常情况时或接收到来自其他节点的视图轮换的消息之后向全网广播视图轮换消息，当序列号等于原主节点序列号加一的新主节点收到超过三分之二的其他节点的合法视图轮换消息，则向其他节点发送新视图消息，其他节点接收到新视图消息后检查签名合法性，检查通过则承认该新的主节点。

进一步的，所述快速批量处理机制：主节点进入专用视图状态后，主节点对接受到的数据上链请求按序号分桶处理，并为每个桶分配一个唯一的打包线程，每个线程独立运行；对于每个桶，当请求的数量达到阈值后，对应的线程开始执行打包，首先对接收到的数据上链请求进行正确性校验，剔除非法请求，将请求按照接收的时间顺序打包成块后进行验证，最后将定序好的数据上链请求信息连同验证结果写入一个预准备消息，放入广播队列，由主节点依次广播给网络中所有节点。

进一步的，所述节点动态增加流程：新增节点主动向现有节点发起连接；现有节点接收到新增节点的连接请求后确认同意该节点加入，然后向全网广播添加节点消息；新增节点加入后产生一个新的主节点，主节点向全网广播完成更新消息；其他节点在收到更新消息后，完成新增节点流程。

进一步的，所述分区管理与分区共识机制：使用链路状态和选举的分簇算法将网络分区，后续加入节点在最近的两个分区中随机选择一个加入，当分区节点超过设定阈值时再次运行分簇算法进行拆分；每个分区内的节点在本区域内进行共识和出块，形成一个联盟链支链，数据写入支链后，各支链经由分区主节点向主链提交锚定请求，主链验证接收到支链的锚定请求之后核查支链提交的签名，核验无误后主链节点按照共识规则进行背书和出块，将数据写入主链，最终完成数据上链。

进一步的，所述基于链路状态和选举的分簇算法：当网络中节点数目达到阈值时，每个节点都向其他节点发送自己的路由信息；各个节点收到其他节点的路由信息后，开始运行链路状态路由算法，使用迪杰斯特拉最短路径算法；运行结束后，得到其它节点的最短路径；得到最短路径后，每个节点开始生成一个随机数，然后比较生成的随机数和预设的随机数阈值，如果大于预设的阈值，则意味着该节点自动选举成为了簇头；簇头向其它所有节点发送入簇邀请消息；普通节点收到所有簇头的请求后，选出路径延迟最低的一个簇，向这个簇发送同意入簇的消息；簇头接收到回复后，把新加入的节点的信息广播到自己的簇内；簇内节点更新自己的路由表信息，普通节点加入簇的过程完成；此时网络完成分区，每个簇即为一个区，每个簇的簇头即为该区的主节点，簇内的其他节点为该区的从节点。

有益效果：本发明提出一种基于高鲁棒性拜占庭容错的联盟链数据安全实时上链方法，与现有技术相比，本发明具有以下优点：

1)动态视图轮换，本发明在原有高鲁棒性拜占庭容错方法的视图轮换基础上，设计了更高效的机制，在系统承受较多的请求冲击时，主节点能够主动发起专用视图请求，从而避免在频繁的视图轮换过程中大量的网络通信开销造成的网络延迟。

2)快速批量处理，在预准备阶段配合动态视图轮换机制，主节点采用多线程方式对数据上链请求进行打包，充分发挥主节点cpu的多核性能，使得打包速度提高，大大加快了上链速度。

3)恶意节点监督，为每个节点设置信任记录，并定期处理隐患节点，用于提升联盟链网络的安全性。

4)分区管理与分区共识，当共识网络中节点较多，数据上链速度下降时，网络中的节点进行分区，分区后各个区域内的节点自行进行共识流程。通过把共识流程分散到各个分区内，提升整个联盟链网络的共识效率，从而提高数据上链速度。

附图说明

图1为本发明流程图；

图2为本发明恶意节点监督机制流程图；

图3为本发明主节点申请专用视图示意图；

图4为本发明主节点异常视图变更示意图；

图5为本发明快速批量处理机制示意图；

图6为本发明网络分区管理示意图；

图7为本发明基于链路状态和选举的分簇算法流程图；

图8为本发明未开启专用视图的实验效果图；

图9为本发明开启专用视图后的实验效果图；

图10为本发明节点数为50时网络运行情况示意图；

图11为本发明节点数提升至100时网络运行情况示意图；

图12为本发明分区管理与分区共识机制开启后加入节点到50时分区情况示意图；

图13为本发明分区内节点数到达20时再次执行分区情况示意图；

图14为本发明应付短时间内大量数据上链请求方法整体执行情况示意图。

具体实施方式

根据具体的实施例和附图，对本发明涉及到的相关的技术进行深入详细地说明和讲解。本发明除了以下即将提及的内容以外，其余的技术和实施条件相关方法均是本领域及其相关领域的普遍知识和公认常识。

本发明提出一种基于高鲁棒性拜占庭容错的联盟链数据安全实时上链方法，该方法在联盟链网络中使用，网络中所有节点遵循恶意节点监督机制；网络允许动态加入节点，若有新增节点加入，则进入节点动态增加流程，增加后若节点数量超过设定阈值，则启动分区管理与分区共识机制；网络中的每条消息都包含消息内容m、m的摘要d(m)、和发送这条消息的节点对d(m)的签名sig；该方法具体包括以下步骤：

步骤1：请求转发

网络中的任意节点接收客户端的数据上链请求，请求的内容包括：o：需要上链的数据内容、t：客户端的时间戳、c：客户端编号；其中，从节点接收到请求之后转发给主节点，主节点自身也能直接接收请求；

步骤2：预准备阶段

主节点等待一个超时时间或接收到满足最大区块大小数量的数据上链请求，计算出本批次的请求从被接收到被处理的平均时间，如果超过给定阈值，则启动动态视图轮换机制；未超过给定阈值，则首先给该批次的请求分配一个编号n，对接收到的数据上链请求逐个进行正确性校验，剔除非法请求，将请求按照接收的时间顺序打包成块后进行验证，最后将定序好的数据上链请求信息连同验证结果写入预准备消息＜＜pre-prepare,v,n,d>,m>，其中v：视图编号，广播给网络中所有节点；

步骤3：准备阶段

从节点在收到主节点的预准备消息后，首先进行签名正确性校验，如果之前从未收到任何v,n,m相同的预准备消息，检查当前的视图与区块号信息，确认无误则接受该预准备消息，将预准备消息存入缓存，并向其他所有节点广播准备消息；

步骤4：提交阶段

从节点对接收到的准备消息进行签名正确性校验并存入缓存，直至收到超过三分之二的其他节点具有相同的v,n,m的准备消息之后，验证对应编号为n的预准备消息，并将验证结果与主节点写入预准备消息中的验证结果进行比对，验证成功则广播提交消息，否则启动主节点的动态视图轮换；

步骤5：写入账本阶段

从节点在收到超过三分之二的其他节点具有相同的v,n,m的提交消息后，将请求上链的数据写入本地账本，返回客户端数据上链成功消息，此时若网络未分区，则完成数据上链，若网络已分区，则完成数据写入支链。

如图2所示，所述恶意节点监督机制：为联盟链网络中每个参与节点设置恶意行为记录值(misbehaviorrecord)，并初始化为0，如果发现有节点有恶意行为，则将次数加一，如果检测到某个节点的恶意行为次数超过上限，则启动清理程序，将该节点从联盟链网络中删除。

这里的恶意行为会发生在如下情形：

1)当发生视图变更时，说明上一个主节点存在异常情况，给上一个主节点的恶意行为记录值加一；

2)节点在每一次收到消息并且检查消息的签名是否正确时，如果消息正确性检查没有通过，那么给发送消息的节点的恶意行为记录值加一；

3)在步骤3提交阶段，从节点检查是否收到了超过三分之二的其他节点的相同消息时，把相同的消息从消息集合中拿出来并且计数，如果数量不足消息总数减一，那么找出没有发送相同消息给本节点的那些节点，并且给那些节点的恶意行为记录值加一。

所述动态视图轮换机制：分别为两种视图轮换：第一种，如图3所示，当主节点有大量的数据上链任务时，向其他节点发送一条申请(dvrequest)使用专用视图消息，从节点收到主节点的消息时，首先检查是否在同一个视图下，再检查请求的完成平均时间是否超过给定阈值，如果在同一视图下并超过阈值则向主节点发送确认消息(dvack)表示同意；主节点收到了相同视图下的确认消息后，进入专用视图状态，主节点发起快速批量处理机制，达到规定时间阈值后，主节点的专用视图状态结束；第二种，如图4所示，其中replica0为原主节点，replica1、replica2、replica3为从节点，当从节点检测到主节点存在异常情况时或接收到来自其他节点的视图轮换的消息之后向全网广播视图轮换消息(view-change)，当序列号等于原主节点序列号加一的新主节点，即replica1，收到超过三分之二的其他节点的合法视图轮换确认消息(view-change-ack)，则向其他节点发送新视图消息(new-view)，其他节点接收到新视图消息后检查签名合法性，检查通过则承认该新的主节点。

如图5所示，所述快速批量处理机制：原先主节点的打包方式相当于单线程形式，对收到的请求按照时间顺序进行打包；主节点进入专用视图状态后，主节点对接受到的数据上链请求按序号分桶处理，如图中示例，把接收到消息的时间戳对4取余就可以得到key值，再将请求消息存到相应key值的集合里就能将所有接收到的消息平均分散到4个桶里，为每个桶分配一个唯一的打包线程，每个线程独立运行；对于每个桶，当请求的数量达到阈值后，对应的线程开始执行打包，首先对接收到的数据上链请求进行正确性校验，剔除非法请求，将请求按照接收的时间顺序打包成块后进行验证，最后将定序好的数据上链请求信息连同验证结果写入一个预准备消息，放入广播队列，由主节点依次广播给网络中所有节点。

所述节点动态增加流程：新增节点主动向现有节点发起连接；现有节点接收到新增节点的连接请求后确认同意该节点加入，然后向全网广播添加节点消息；新增节点加入后产生一个新的主节点，主节点向全网广播完成更新消息；其他节点在收到更新消息后，完成新增节点流程。

所述分区管理与分区共识机制：使用链路状态和选举的分簇算法将网络分区，如图6所示，给出了节点分区的示意图，后续加入节点在最近的两个分区中随机选择一个加入，当分区节点超过设定阈值时再次运行分簇算法进行拆分；每个分区内的节点在本区域内进行共识和出块，形成一个联盟链支链，数据写入支链后，各支链经由分区主节点向主链提交锚定请求，主链验证接收到支链的锚定请求之后核查支链提交的签名，核验无误后主链节点按照共识规则进行背书和出块，将数据写入主链，最终完成数据上链。

所述基于链路状态和选举的分簇算法：如图7所示，网络中允许节点的动态加入，当网络中节点数目达到给定阈值时，网络中的节点进行分区，每个节点都向其他节点发送自己的路由信息；各个节点收到其他节点的路由信息后，运行迪杰斯特拉最短路径算法得到到达其它节点的最短路径；每个节点生成一个随机数，然后比较生成的随机数和预设的随机数阈值，如果大于预设的阈值，则意味着该节点自动选举成为了簇头；簇头向其它所有节点发送入簇邀请消息；普通节点收到所有簇头的请求后，选出路径延迟最低的一个簇，向这个簇发送同意入簇的消息；簇头接收到回复后，把新加入的节点的信息广播到自己的簇内；簇内节点更新自己的路由表信息，普通节点加入簇的过程完成；此时网络完成分区，每个簇即为一个区，每个簇的簇头即为该区的主节点，簇内的其他节点为该区的从节点。

为了验证本发明的实际效果，设计了如下实验。使用java语言实现了高鲁棒性拜占庭容错方法和本发明的方法进行对比。实验环境配置为intelcorei5处理器、3.2ghz主频和12g内存。

为了验证在主节点在应对短时间内大量数据上链请求时，本发明中的专用视图和快速批量处理机制的性能，设置模拟客户端发送请求的间隔为2ms，主节点打包的时间间隔为300ms，请求最大超时时间为2000ms，并设置了每秒显示一次打包信息和模拟客户端状态报告，如果从节点发起了视图变更，则显示一行“id：1issuedviewchange，，，，”的消息。

不开启专用视图时运行状态如图8所示，可以看到系统正常运行了4到5秒后，备份节点全部开始发起视图变更；再观察客户端报告，可以看到请求完成率在慢慢降低。对于客户端来说，上链失败率增高，上链速度受到很大影响。延迟没有明显变化是因为模拟客户端最后根本收不到回复消息。

开启专用视图时运行情况如图9所示，可以看到运行较长时间后客户端的请求完成率依然接近百分之百，打包的节点还是id为0的主节点，整个共识网络的运行非常稳定。因此可以断定，共识网络的性能有了很大的提升。

为了验证分区管理与分区共识机制的有益效果，首先设置模拟客户端每100ms发送一次请求，节点数目为50，网络运行情况如图10所示：可以看到共识网络运行稳定，延迟在310ms左右。当把网络总节点数量提升至100时，网络运行情况如图11所示：可以看到共识网络运行稳定，请求完成率始终保持非常高的水平，但是请求完成的平均延迟达到了接近600ms，所以可以推断出节点的增加是不利于数据的快速上链的，节点越多延迟越高。接下来，开启分区管理与分区共识机制，首先每200ms加入一个节点，加到50个节点后，开始执行分区；分区完成后，模拟客户端开始不间断发送请求；7秒后开始每隔一秒加入一个新节点，图12是节点加入网络的过程、选举出的簇头信息和每个节点加入新的簇后的信息(最下方缩进的若干行，包括它的新id，簇内节点总数以及所在簇的簇头的ip)：图13显示的是分区后接收请求并开始稳定运行共识算法的过程。在78号节点加入网络时，加入的簇超过了20个节点，再次执行分区，紧接着的两行是两个新簇的簇头信息，再接下来的19行是普通节点各自加入两个簇头的信息；再次分区后共识又可以继续进行，可以看到共识网络运行稳定，共识达成的延迟稳定在250ms左右，并且完成率接近百分之百，较没有分区管理与分区共识机制时有了很大的提升。

为了验证本发明方法整体的鲁棒性和可用性，设置：每0.5s网络中加入一个节点，到了51个时执行分区；分区完成后，模拟客户端每100ms发送一个请求，这时请求数量属于比较少的；再过4秒后，客户端开始发送大量的请求到其中一个分区，发送间隔为2ms(这个请求数量足够引发主节点发起专用视图申请)。如图14所示，可以看到已经有60多个节点加入到共识网络中来，而且还在不停地加入。因为请求数量太大，共识网络处理不过来，所以可以看见客户端报告显示的平均完成率只有百分之三四十，并且还在不断降低，延迟达到了一千多毫秒。主节点感知到延迟增大，就发起了专用视图请求；从节点收到请求后，响应了主节点的请求，可以看见图中的连续的14行加粗部分，就是从节点做出响应的信息。从节点响应完成后，可以看到一行行的“usebatchpacking”信息，这意味着主节点启动快速批量处理机制，开始批量处理请求。后面的客户端状态报告显示了完成率没有下降并且逐步稳定，甚至有些许提升，之后的节点也能够正常加入网络。