一种面向联盟链的交叉容错方法与流程

1.本发明涉及区块链应用技术领域，尤其涉及一种面向联盟链的交叉容错方法。


背景技术：

2.随着区块链(blockchain，又被称为分布式共享账本)应用范围的逐步扩大，得到了产业界和学术界的广泛关注。区块链作为分布式系统，从访问控制的角度可分为公有链、联盟链和私有链。而共识算法在分布式系统中对维护数据一致性、保证系统安全性和可靠性方面起着决定性作用。目前，在公有链中基本采用pow等非确定算法，联盟链和私有链中主要采用pbft系列确定性算法。然而它们都存在扩展性问题，同时传统的paxos、raft等算法又不适用于拜占庭容错环境，因此，我们提出一种面向联盟链的交叉容错方法来解决以上问题。


技术实现要素：

3.本发明提出的一种面向联盟链的交叉容错方法,解决了背景技术中的问题。
4.为了实现上述目的，本发明采用了如下技术方案：
5.一种面向联盟链的交叉容错方法，包括以下步骤：
6.s1、fabric中实现xraft排序后端；
7.s2、各个xraft orderer group内选举产生自己的leader节点，而后各group内的leader按顺时针向下一个group发生本组的leader标识消息
8.s3、议员之间运行xraft算法，产生自己的leader节点；
9.s4、shard master集群内部故障处理，将通知该故障节点所在group的leader重新推举新的议员节点；
10.s5、处理负载和故障；
11.所述s5具体包括：
12.步骤1：对于每个group维持这样一个元组<capacity(k),active degree(k)，dependency(k)>,其中capacity(k)表示一段时间内第k个group收到的请求总数，active degree(k)表示第k个group单位时间内平均处理的事务，dependency(k)表示第k组请求对shard master的依赖情况；
13.步骤2：系统依据公式对负载过重的group内的议员进行调整。
14.优选的，所述s1中包括以下步骤：
15.s11：实现chain接口和consentersupport接口；
16.s12：读取xraft配置参数，初始化xraft集群；
17.s13：在chain接口的order方法中，调用xraft算法，接收消息，并在各个节点同步数据；
18.s14：在consentersupport的blockcutter方法中，获取xraft的commitlog，进行区
块打包；
19.s15：适配consenter、chain及consentersupport内的方法。
20.优选的，步骤s2包括以下步骤：
21.s21：如果下一个group内尚未产生leader节点，则忽略该消息；
22.s22：产生leader节点后，该组内的任何一个非leader节点收到该消息后都转发给本组的leader节点，leader节点收到m
gl
消息后，根据已知的group配置信息和签名验证消息的合法性；
23.s23：验证通过后，记录group x的leader为j，并附带t 1个成员的投票信息发往下一个组；
24.s24：在继续发往下一个组之前leader节点可以把上一个组的投票信息去除，只保留自己组的投票，同时将本组的leader信息附加在内往下传递；
25.s25：消息的合法性验证过程也只验证上一组的投票信息与原始签名，直至发送该消息的leader节点收到了自己发送的m
gl
消息，该leader节点可以确定其他组内已经产生leader节点并且均已知道group x的leader为j；
26.s26：leader节点收到自己发送过的m
gl
消息后检查是否附带有其他group的leader信息，如果附有其他leader信息，则记录该信息并将附带的信息继续往下发送。
27.优选的，步骤s3包括以下步骤：
28.s31：leader依据自己所在group内的配置信息随机产生一个节点s作为议员，并为该议员收集本组内的t 1个签名信息形成
29.s32：该消息由leader节点发送给下一组的leader，收到该消息的leader节点检查消息的合法性并且如果本组内已经产生议员节点，则把该消息公布给本组的议员节点；
30.s33：直至leader收到了自己发送的m
s
消息，则通知本组议员节点，当议员节点收集到|group|个议员信息后，则与其他group的议员共同组成逻辑上的shard master集群。
31.优选的，步骤s4中，议员推选算法包括以下步骤：
32.s41：当xraft group内的leader节点失效时，该组内的议员节点将报告该信息，并等待新的leader产生；
33.s42：议员节点将对本组内的负载情况进行监测和其他议员节点的响应速度进行监测；
34.s43：当发现某个议员节点由于本组的负载响应速度变慢时，可以向负载较轻的group申请临时议员节点，该议员节点变为master组内的passive节点；
35.s44：当负载恢复后，该议员节点重新恢复active状态，停用临时议员节点。
36.优选的，所述s5中，包括以下公式：
[0037][0038]
score(k)＝wl(k)
·
e
‑
dependency(k)
ꢀꢀꢀꢀꢀꢀꢀ
(2)
[0039]
按公式(1)对每个group负载进行计算，当系统中某个group的wl(k)大于某个预置的参数α时，则说明该group负载过高，group负载过高，按公式(2)对每个group的情况进行评价，然后从k个group内选择得分较高的委派leader节点再指定一个临时议员加入到
shard master组代替负载过高的group的议员。
[0040]
优选的，每个group内至少有一个节点作为议员节点；每个group内至少同时有两个节点处于正常工作状态。
[0041]
优选的，步骤s3中算法为以下算法：
[0042][0043][0044]
本发明的有益效果是：
[0045]
本发明以peerreview为基础，使得xpaxos算法的fd中只能发现当前的视图中存在故障节点的情况变为可以定位到具体的故障节点，从而简单的将该故障节点隔离为passive节点，提高了故障恢复的速度。
[0046]
本发明算法不需要在每次故障恢复环节都需要变换主节点和变更视图。只要原来的leader节点通过peer视角证明是运行良好的，就没有必要把主节点替换掉，从而减少了全局配置信息的变更。由于节点的状态可以被检测到，在换入新的节点时，只要将leader节点的状态完整的复制给新加入进来的节点。本发明在小范围内进行一致性检查，降低了算法视图变更的复杂度。
附图说明
[0047]
图1为本发明的hlf整体架构示意图。
[0048]
图2为本发明的hlf工作流程。
[0049]
图3为hlf网络中的orderer服务示意图。
[0050]
图4为orderer主要结构示意图。
[0051]
图5为multiledger的主要结构示意图。
[0052]
图6为consenter接口及其实现结构示意图。
[0053]
图7为xraft排序后端中的chainimpl类图。
[0054]
图8为sharding orderer拓扑结构示意图。
[0055]
图9为本发明的自适应shards拓扑结构。
具体实施方式
[0056]
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。
[0057]
参照图1
‑
9，一种面向联盟链的交叉容错方法，包括以下步骤：
[0058]
s1、fabric中实现xraft排序后端；
[0059]
s2、各个xraft orderer group内选举产生自己的leader节点，而后各group内的leader按顺时针向下一个group发生本组的leader标识消息
[0060]
s3、议员之间运行xraft算法，产生自己的leader节点；
[0061]
s4、shard master集群内部故障处理，将通知该故障节点所在group的leader重新推举新的议员节点；
[0062]
s5、处理负载和故障；
[0063]
所述s5具体包括：
[0064]
步骤1：对于每个group维持这样一个元组<capacity(k),active degree(k)，dependency(k)>,其中capacity(k)表示一段时间内第k个group收到的请求总数，active degree(k)表示第k个group单位时间内平均处理的事务，dependency(k)表示第k组请求对shard master的依赖情况；
[0065]
步骤2：系统依据公式对负载过重的group内的议员进行调整。
[0066]
如图1所示，hlf v1.0的设计体现了高度模块化的思想。在该版本中，将orderer排序节点(共识机制)独立出来，实现了可插拔的特点。将证书管理作为单独的服务模块，与hlf项目分离，形成了fabric ca，用来处理证书的发放与撤销。区块链应用程序可以通过hlf提供的api来访问系统内部的逻辑结构，包括账本、交易和链码等。账本是区块链系统最核心的概念，是数据记录的实体。应用程序通过修改账本的状态，实现资产的转移。链码(其他区块链系统中也叫做智能合约)则定义了状态转移的规则，构成了区块链应用的基础。在hyperledger fabric中，更提出了通道(channel)的概念，将不同的应用和业务逻辑和通道相关联，实现了不同业务的隔离。这样一来，使得数据的安全性进一步的到保证。
[0067]
如图2所示，hlf通过各个模块之间相互协作完成整个交易流程。在交易过程中，各个模块的协作关系。客户端程序通过fabric平台提供的sdk调用系统底层的接口，以ca颁发
的数字证书作为加入网络通道的凭证。在交易的初始阶段，首先要由客户端发起提议(proposal)。该提议发送到有效的背书节点(endorser)进行背书。当客户端收集到的背书响应符合背书策略之后才能构造出合法的交易请求。交易请求会被提交给排序节点(orderer)进行进一步处理。排序节点会根据收到的交易请求进行全局排序，将符合条件的交易打包成区块。同时客户端可以利用事件监听机制来确认交易是否被成功接收。
[0068]
hlf中的背书节点提供processproposal方法供客户端访问，完成对交易提案的背书处理。该处理过程主要是由受信任的背书节点对交易提案进行签名。当交易收集到足够多的签名后才能被fabric网络接受。在收到来自客户端的交易提案后，背书节点首先检查发送提案交易的客户端的证书信息是否合法，然后对交易进行模拟执行，并记录交后账本状态的变化。背书节点的工作由网络中的部分peer节点来完成。
[0069]
排序节点(orderer)只负责排序工作。为了保证网络中所有合法交易的顺序，排序节点对于提交的交易进行全局排序，并有后端程序将交易打包成区块结构。本文所讨论的xraft在hlf中主要起到排序后端的作用。排序节点一般情况下不关心交易的具体内容，将其透明对待。该模块主要提供broadcast和deliver两个远程过程调用供其他模块调用。
[0070]
committer节点的主要任务是维护区块链和账本状态，这其中包括状态、历史和索引数据等等。committer节点定期的从orderer节点批量获取最新的区块信息，并对这些区块进行最终确认。检查通过后执行交易，并更新相关的信息。peer节点可以只负责背书或者提交一种角色，也可以在同一个peer节点中同时执行这两种不同的任务。
[0071]
如图3所示，在超级账本fabric中，共识指的是网络内节点之间始终保持同样的状态，这样对于同样顺序到达的事物就能进行相同的处理。维护fabric网络达成共识的操作包括背书、排序和验证三个阶段，其中最重要的就是排序。所有的交易在经过committer节点验证和提交之前，都要通过排序服务获得全局的有序性。即排序服务提供了原子广播的作用。在fabric v1.0版本中，排序服务有独立的orderer模块来实现。orderer本身包括三部分内容：一是通过grpc提供对外接口，二是由账本组件来为不同通道维护的区块链结构，三是具体的排序后端。整个排序服务的在hlf网络中的位置。
[0072]
orderer对外提供了两个接口：
[0073]
1)broadcast(srv ab.atomicbroadcast_broadcastserver)
[0074]
2)deliver(srv ab.atomicbroadcast_broadcastserver)
[0075]
如图4所示，其中，broadcast将客户端的请求发送到orderer节点进行排序操作，而peer节点通过deliver批量拉取排序好的区块。orderer服务的关键结构。orderer节点通过server对这两个接口进行了封装，其中processor结构对通道配置进行update操作，multiledger维护fabric网络中的链和账本结构。
[0076]
如图5所示，orderer节点本身需要维护近期生成的区块，超级账本fabric支持三种类型的存储格式：1)ram：将数据存储在内存中；2)file：以文件形式保存到本地；3)json：以文件形式保存，存储格式为json。orderer节点维护的数据只包含区块链结构，不需要保存状态信息。区块链是通过multiledger结构进行维护的，其中最主要的是chains、systemchannel、后端共识算法(插件)的调用接口consenter、账本文件和用于签名的signer。multiledger提供的主要方法包括对chainsupport进行访问的getchain，生成新的配置管理的newchannelconfig以及获取系统channel id的systemchannelid。而各种类型
的账本结构都实现了append、height和iterator方法，从而实现对账本的追加、获取区块总数以及迭代查询账本信息。
[0077]
在本实施例中，fabric v1.0本身提供了solo模式和kafka共识模块。如图6所示本发明在此基础上扩展了基于xraft的consenter实现。
[0078]
如图7所示，相应地，chain接口需要提供不同版本的实现。这是因为chain和排序后端算法密切相关。chain的start方法在orderer启动时会被调用，进行相关信息的初始化。
[0079]
xraft排序后端实现了chain接口，其中的simpleconsenter结构对xraft算法进行了封装。msg是各个排序后端之间传递的消息，该消息被signer通过本地私钥进行签名。消息本身附带了数据部分的摘要信息，以保证消息在各个节点之间的传输过程中不会被篡改。
[0080]
总体来说，在fabric中实现xraft排序后端需要以下步骤：(1)实现chain接口和consentersupport接口。(2)读取xraft配置参数，初始化xraft集群(默认与orderer节点对应)(3)在chain接口的order方法中，调用xraft算法，接收消息，并在各个节点同步数据。(4)在consentersupport的blockcutter方法中，获取xraft的commitlog，进行区块打包。(5)适配consenter、chain及consentersupport内的其他方法。
[0081]
sharding算法的主要思想是把算力平均分到不同的委员会(committees)，每个委员会处理相互独立的事务(shards)。具体过程包括下面的五步：
[0082]
1)标识建立和委员会组建。每个处理机本机生成一个标识，这其中包括公钥、ip以及pow的结论。
[0083]
2)确立委员会覆盖(overlay setup for committees)。在这一步里，处理机之间相互通信，来发现在同一个committee内的其他处理机。
[0084]
3)委员会内部共识。
[0085]
4)最终共识广播。
[0086]
5)随机序列生成。终止委员会(final committee)在大范围内生成一个有限的随机数集合，这些随机数被广播到全网，用作下一个阶段的pow。
[0087]
在开放的网络环境下进行sharding的难题在于各个节点没有确定的身份标识，而在联盟链等具有明确身份标识的场景下实现sharding相对简单。本节其余的部分将讨论如何在超级账本fabric环境下对xraft进行sharding以及相应的sharding策略。
[0088]
超级账本fabric将区块网络配置为不同的通道，根据不同的业务对象使得彼此隔离。基于此，可以构建分区账本(shards ledger)。将同一个通道中的事物映射到同一个orderer group。这样通过有效的sharding策略，可以进一步提高系统的吞吐量。
[0089]
由若干个基于xraft算法orderer节点构成shard master集群，用于对分区的元数据达成共识。master集群定期将元数据打包成区块，形成元数据区块链。具体各个通道上的应用事务区块由各个orderer group进行构造。
[0090]
如图8所示，给出的网络拓扑结构虽然可以起到消息隔离、提高系统吞吐量的目的，但是shard master集群容易成为整个系统的瓶颈。另外，该集群负责元数据的共识，其安全性对整个系统不言而喻。如何去动态的调整shard master集群的组成，使其具有高度的自适应性和可靠性也就成了另一个值得研究的问题。也强调了动态拓扑结构相对于传统
的静态主从拓扑结构的优势。本节针对此问题提出一种新的结构，如图9所示，该图中gi表示不同的orderer group，由实际存在的物理节点上构成，彼此互通；m表示shard master集群，该master集群是逻辑上的结构，实际服务由不同的group共同参与完成。
[0091]
系统初始化时，在各个xraft orderer group内选举产生自己的leader节点。而后各group内的leader按顺时针向下一个group发生本组的leader标识消息如果下一个group内尚未产生leader节点，则忽略该消息。产生leader节点后，该组内的任何一个非leader节点收到该消息后都转发给本组的leader节点。leader节点收到m
gl
消息后，根据已知的group配置信息和签名验证消息的合法性。验证通过后，记录group x的leader为j，并附带t 1个成员的投票信息发往下一个组。为了进一步节省带宽，在继续发往下一个组之前leader节点可以把上一个组的投票信息去除，只保留自己组的投票，同时将本组的leader信息附加在内往下传递。消息的合法性验证过程也只验证上一组的投票信息与原始签名。直至发送该消息的leader节点收到了自己发送的m
gl
消息，该leader节点可以确定其他组内已经产生leader节点并且均已知道group x的leader为j。leader节点收到自己发送过的m
gl
消息后检查是否附带有其他group的leader信息。如果附有其他leader信息，则记录该信息并将附带的信息继续往下发送。
[0092]
leader依据自己所在group内的配置信息随机产生一个节点s作为议员，并为该议员收集本组内的t 1个签名信息形成该消息由leader节点发送给下一组的leader。收到该消息的leader节点检查消息的合法性并且如果本组内已经产生议员节点，则把该消息公布给本组的议员节点。直至leader收到了自己发送的m
s
消息，则通知本组议员节点。当议员节点收集到|group|个议员信息(包括自己)后，则与其他group的议员共同组成逻辑上的shard master集群。议员之间运行xraft算法，产生自己的leader节点。
[0093][0094]
shard master集群内部发生故障时，将通知该故障节点所在group的leader重新推举新的议员节点。当xraft group内的leader节点失效时，该组内的议员节点将报告该信息，并等待新的leader产生。议员节点将对本组内的负载情况进行监测和其他议员节点的响应速度进行监测。当发现某个议员节点由于本组的负载响应速度变慢时，可以向负载较轻的group申请临时议员节点，该议员节点变为master组内的passive节点。当负载恢复后，该议员节点重新恢复active状态，停用临时议员节点。
[0095]
在议员推选算法中，2至3行是每个group内部产生leader节点以及议员节点。算法第4至11行是leader节点收到m
s
消息的应答方案，第5行接收消息并对消息的合法性进行验证；第6至7行，如果在group内存在议员节点，则该leader节点通知议员节点m
s
消息内所包含的议员节点信息；第8行，如果该group内尚未产生议员节点，则leader只将该信息记录下来；第9至11行，如果leader节点收到了自己发送过的消息，则通知group内的议员节点，否则继续往下一个group传递；第12至14行，如果议员节点确认所有的group均产生议员节点或者已收到通知，则加入到shard master group内。
[0096]
对于负载和故障情况，对于每个group维持这样一个元组<capacity(k),active degree(k)，dependency(k)>,其中capacity(k)表示一段时间内第k个group收到的请求总
数，active degree(k)表示第k个group单位时间内平均处理的事务，dependency(k)表示第k组请求对shard master的依赖情况(即发生leader重新选举或者议员节点发生故障的次数)。系统依据以下公式对负载过重的group内的议员进行调整：
[0097][0098]
score(k)＝wl(k)
·
e
‑
dependency(k)
ꢀꢀꢀꢀꢀꢀꢀ
(2)
[0099]
按公式1对每个group负载进行计算，当系统中某个group的wl(k)大于某个预置的参数α时，则说明该group负载过高。此时按公式2对每个group的情况进行评价，然后从k个group内选择得分较高的委派leader节点再指定一个临时议员加入到shard master组代替负载过高的group的议员作。
[0100]
该过程要保证以下两点：
[0101]
1)每个group内至少有一个节点作为议员节点；
[0102]
2)每个group内至少同时有两个节点处于正常工作状态。
[0103]
本发明以peerreview为基础，使得xpaxos算法的fd中只能发现当前的视图中存在故障节点的情况变为可以定位到具体的故障节点，从而简单的将该故障节点隔离为passive节点，提高了故障恢复的速度。本发明算法不需要在每次故障恢复环节都需要变换主节点和变更视图。只要原来的leader节点通过peer视角证明是运行良好的，就没有必要把主节点替换掉，从而减少了全局配置信息的变更。由于节点的状态可以被检测到，在换入新的节点时，只要将leader节点的状态完整的复制给新加入进来的节点。本发明在小范围内进行一致性检查，降低了xpaxos算法视图变更的复杂度。