本发明涉及分布式计算技术,尤其涉及一种分布式系统及消息处理方法。
背景技术:
分布式系统是目前普遍使用的计算系统,应用于区块链、ZooKeeper分布式服务框架等等诸多领域。
分布式系统的工作过程中,需要对来自客户端的待处理的消息形成共识(Consensus),即分布式系统的全部节点或多数节点对接收的消息进行确认,然后对消息进行同步存储/处理。
例如,当分布式系统应用在私有区块链或联盟区块链中时,各节点对于客户端提交的交易记录的根据共识算法形成共识(即确认交易记录的可靠性),会在各个节点的维护的区块链中存储,保证了各个节点存储的交易记录的一致性。
分布式系统目前采用的共识算法往往侧重于达成共识的效率,或在达成共识的过程中保证一定的容错性能,容错性能是指存在故障节点或恶意节点时,保证多数的节点仍然能够达成共识。
对于相关技术提供的用于保证达成共识的效率的共识算法来说,由于无法检测故障节点和恶意节点,因此难以保证共识的可靠性。
技术实现要素:
本发明实施例提供一种分布式系统及消息处理方法,能够保证节点针对消息高效达成共识的同时,还能够检测异常节点。
本发明实施例的技术方案是这样实现的:
第一方面,本发明实施例提供一种分布式系统,包括:
客户端和多个节点;
所述节点,用于在第一共识模式中新的共识周期到达时,通过执行选举操作确定处于主节点的状态或处于从节点的状态;其中,
所述节点,还用于处于主节点的状态时,验证所述客户端发送的消息的数字签名,将所述消息发送到所述从节点;接收到超出预定数量的所述从节点的确认接收通知并验证所述确认接收通知的数字签名,持久化存储所述消息,向所述从节点发送存储消息通知;
所述节点,还用于处于从节点的状态时,接收到所述主节点发送的所述消息时向所述客户端返回结果;验证所接收的消息的数字签名,向所述主节点发送确认接收通知;验证所接收的存储消息通知的数字签名,持久化存储所接收的消息;
所述客户端,用于根据所述从节点接收到所述消息时返回的结果,确定异常节点。
第二方面,本发明实施例提供一种消息处理方法,包括:
在第一共识模式中新的共识周期到达时,分布式系统中的节点通过执行选举操作处于主节点的状态或处于从节点的状态;其中,
所述节点处于主节点的状态时接收所述客户端的消息,验证所述消息的数字签名,将所述消息发送到所述从节点;
所述节点处于从节点的状态时,接收到所述主节点发送的所述消息并向所述客户端返回结果,验证所接收的消息的数字签名后向所述主节点发送确认接收通知;
所述节点处于主节点的状态时,接收到超出预定数量的所述从节点的确认接收通知,验证所述确认接收消息的数字签名后持久化存储所述消息,向所述从节点发送存储消息通知;
所述节点处于从节点的状态时,验证所接收的存储消息通知的数字签名后持久化存储所接收的消息;
所述客户端根据所述从节点接收到所述消息时返回的结果,确定异常节点。
第三方面,本发明实施例提供一种消息处理方法,应用于分布式系统中的节点,包括:
在第一共识模式中新的共识周期到达时,分布式系统中的节点通过执行选举操作处于主节点的状态或处于从节点的状态;其中,
所述节点处于主节点的状态时接收所述客户端的消息,验证所述消息的数字签名,将所述消息发送到所述从节点;
所述节点处于从节点的状态时,接收到所述主节点发送的所述消息并向所述客户端返回结果,验证所接收的消息的数字签名后向所述主节点发送确认接收通知;
所述节点处于主节点的状态时,接收到超出预定数量的所述从节点的确认接收通知,验证所述确认接收消息的数字签名后持久化存储所述消息,向所述从节点发送存储消息通知;
所述节点处于从节点的状态时,验证所接收的存储消息通知的数字签名后持久化存储所接收的消息;
所述消息,用于供客户端确定异常节点。
上述方案中,所述从节点向所述客户端返回结果携带所述消息的唯一性字段和所述从节点的数字签名,用于供所述客户端验证所接收结果的数字签名后,将所接收结果包括唯一性字段与所发送消息的唯一性字段比较,确定不一致的唯一性字段对应的从节点为出错节点,以及确定未返回相应结果的从节点为故障节点。
上述方案中,所述从节点所返回的结果还携带所述从节点所接收消息的序列号,用于供所述客户端根据所接收结果携带的序列号与所发送消息的序列号比较,当发送不一致序列号的从节点的数量超出不一致数量阈值时,判定所述主节点为恶意节点。
上述方案中,还包括:
所述节点在所述客户端确定所述主节点为恶意节点,或者,确定所述从节点中存在故障节点时,切换到第二共识模式。
上述方案中,还包括:
所述节点在切换到所述第二共识模式的准备阶段,将所述节点持久化存储的消息的哈希值与其他节点持久化存储的消息的哈希值比较,确认一致时向所述客户端发送携带相应节点的数字签名的一致性确认;
所述一致性确认,用于供所述客户端在预定时间内接收到全部所述节点的一致性确认时,通知全部所述节点继续切换到所述第一共识模式;未在预定时间内接收到全部所述节点的一致性确认时,通知全部所述节点继续切换到所述第二共识模式。
上述方案中,还包括:
所述节点在切换到所述第二共识模式的准备阶段,将所述节点持久化存储的消息的哈希值与其他节点持久化存储的消息的哈希值比较,确认一致时向消息的发送节点发送携带相应节点的数字签名的数据确认;
所述数据确认,用于供所述客户端在预定时间内达成共识的节点未接收到未达成共识的节点的数据确认时,或在预定时间内任一节点未接收到其他节点发送的数据确认时,触发所述分布式系统的节点继续切换到所述第二共识模式。
上述方案中,还包括:
所述主节点在所述第二共识模式中统计到与所述从节点针对所接收的消息形成共识的次数超过主节点共识次数阈值时,与所述从节点切换到所述第一共识模式。
上述方案中,所述主节点在所述第二共识模式中统计到与所述从节点针对所接收的消息形成共识的次数超过主节点共识次数阈值时,与所述从节点切换到所述第一共识模式,包括:
所述主节点在所述第二共识模式中统计到针对所接收的消息形成共识的次数超过所述主节点共识次数阈值时,向所述从节点发送切换到所述第一共识模式的通知,并在接收到全部所述从节点发送的切换确认时,与所述从节点保持节点的状态切换到所述第一共识模式。
上述方案中,还包括:
所述从节点在接收到切换到所述第一共识模式的通知时,统计到针对所接收的消息形成共识的次数超过从节点共识次数阈值时,向所述主节点发送切换确认。
上述方案中,所述从节点未接收到所述主节点的心跳信息时,或者,所述主节点为恶意节点时,通过执行选举操作确定处于主节点的状态或处于从节点的状态。
上述方案中,所述节点在新的共识周期到达、且未接收到其他节点发送的心跳信息时,向所述其他节点发送选举请求,所述选举请求携带所述节点的数字签名,当接收预定数量的其他节点返回的选举确认时,转换为主节点的状态,定期向所述其他节点发送心跳信息;其中,所述选举确认为所述其他节点验证所述选取请求携带的数字签名后发送;
所述节点在新的共识周期到达、且接收到其他节点发送的心跳信息时转换为从节点的状态。
第四方面,本发明实施例提供一种分布式系统中的节点,包括:
选举单元,用于在第一共识模式中新的共识周期到达时,通过执行选举操作确定处于主节点的状态或处于从节点的状态;其中,
主节点单元,用于当所述节点处于主节点的状态时接收所述客户端的消息,验证所述消息的数字签名,将所述消息发送到所述从节点;
从节点单元,用于当所述节点处于从节点的状态时,接收到所述主节点发送的所述消息并向所述客户端返回结果,验证所接收的消息的数字签名后向所述主节点发送确认接收通知;
所述主节点单元,用于当所述节点处于主节点的状态时,接收到超出预定数量的所述从节点的确认接收通知,验证所述确认接收消息的数字签名后持久化存储所述消息,向所述从节点发送存储消息通知;
所述从节点单元,用于当所述节点处于从节点的状态时,验证所接收的存储消息通知的数字签名后持久化存储所接收的消息;所述消息用于供客户端确定异常节点。
上述方案中,所述从节点向所述客户端返回结果携带所述消息的唯一性字段和所述从节点的数字签名,用于供所述客户端验证所接收结果的数字签名后,将所接收结果包括唯一性字段与所发送消息的唯一性字段比较,确定不一致的唯一性字段对应的从节点为出错节点,以及确定未返回相应结果的从节点为故障节点。
上述方案中,所述从节点所返回的结果还携带所述从节点所接收消息的序列号,用于供所述客户端根据所接收结果携带的序列号与所发送消息的序列号比较,当发送不一致序列号的从节点的数量超出不一致数量阈值时,判定所述主节点为恶意节点。
上述方案中,还包括:
切换单元,用于在所述客户端确定所述主节点为恶意节点,或者,确定所述从节点中存在故障节点时,切换到第二共识模式。
上述方案中,所述切换单元,还用于在切换到所述第二共识模式的准备阶段,将所述节点持久化存储的消息的哈希值与其他节点持久化存储的消息的哈希值比较,确认一致时向所述客户端发送携带相应节点的数字签名的一致性确认;
所述一致性确认,用于供所述客户端在预定时间内接收到全部所述节点的一致性确认时,通知全部所述节点继续切换到所述第一共识模式;未在预定时间内接收到全部所述节点的一致性确认时,通知全部所述节点继续切换到所述第二共识模式。
上述方案中,所述切换单元,还用于在切换到所述第二共识模式的准备阶段,将所述节点持久化存储的消息的哈希值与其他节点持久化存储的消息的哈希值比较,确认一致时向消息的发送节点发送携带相应节点的数字签名的数据确认;
所述数据确认,用于供所述客户端在预定时间内达成共识的节点未接收到未达成共识的节点的数据确认时,或在预定时间内任一节点未接收到其他节点发送的数据确认时,触发所述分布式系统的节点继续切换到所述第二共识模式。
上述方案中,所述主节点单元,还用于当所述节点处于主节点的状态,并在所述第二共识模式中统计到与所述从节点针对所接收的消息形成共识的次数超过主节点共识次数阈值时,与所述从节点切换到所述第一共识模式。
上述方案中,所述主节点单元,还用于在所述第二共识模式中统计到针对所接收的消息形成共识的次数超过所述主节点共识次数阈值时,向所述从节点发送切换到所述第一共识模式的通知,并在接收到全部所述从节点发送的切换确认时,与所述从节点保持节点的状态切换到所述第一共识模式。
上述方案中,所述从节点单元,还用于当所述节点处于从节点的状态时,在接收到切换到所述第一共识模式的通知时,统计到针对所接收的消息形成共识的次数超过从节点共识次数阈值时,向所述主节点发送切换确认。
上述方案中,所述选举单元,还用于当未接收到所述主节点的心跳信息时,或者,所述主节点为恶意节点时,通过重新执行选举操作确定处于主节点的状态或处于从节点的状态。
上述方案中,所述选举单元,还用于当在新的共识周期到达、且未接收到其他节点发送的心跳信息时,向所述其他节点发送选举请求,所述选举请求携带所述节点的数字签名,当接收预定数量的其他节点返回的选举确认时,转换为主节点的状态,定期向所述其他节点发送心跳信息;其中,所述选举确认为所述其他节点验证所述选取请求携带的数字签名后发送;
所述选举单元,还用于当在新的共识周期到达、且接收到其他节点发送的心跳信息时转换为从节点的状态。
第五方面,本发明实施例提供一种消息处理方法,包括:
向分布式系统的节点中的主节点发送消息,所述消息携带所述客户端的数字签名;
其中,所述数字签名用于供所述主节点进行验证,并将所接收的消息携带所述主节点的数字签名,发送给所述分布式系统中的从节点;
接收所述从节点在接收到所述消息时返回的结果;
根据所述从节点接收到所述消息时返回的结果,确定异常节点。
第六方面,本发明实施例提供一种客户端,包括:
通信单元,用于向分布式系统的节点中的主节点发送消息,所述消息携带所述客户端的数字签名;
其中,所述数字签名用于供所述主节点进行验证,并将所接收的消息携带所述主节点的数字签名,发送给所述分布式系统中的从节点;
所述通信单元,用于接收所述从节点在接收到所述消息时返回的结果;
检测单元,用于根据所述从节点接收到所述消息时返回的结果,确定异常节点。
上述方案中,所述检测单元,还用于验证所接收结果的数字签名后,将所接收结果包括唯一性字段与所发送消息的唯一性字段比较,确定不一致的唯一性字段对应的从节点为出错节点,以及确定未返回相应结果的从节点为故障节点。
上述方案中,所述检测单元,还用于根据所接收结果携带的序列号与所发送消息的序列号比较,当发送不一致序列号的从节点的数量超出不一致数量阈值时,判定所述主节点为恶意节点。
上述方案中,还包括:
切换单元,用于确定所述主节点为恶意节点,或者,确定所述从节点中存在故障节点时,触发所述分布式系统的节点切换到第二共识模式。
上述方案中,所述切换单元,还用于在预定时间内接收到全部所述节点的一致性确认时,通知全部所述节点返回所述第一共识模式;未在预定时间内接收到全部所述节点的一致性确认时,通知全部所述节点继续切换到所述第二共识模式;
其中,所述一致性确认,为各所述节点在切换到所述第二共识模式的准备阶段,将各所述节点持久化存储的消息的哈希值与其他节点持久化存储的消息的哈希值比较,并在确认一致时发送,且携带相应节点的数字签名。
上述方案中,所述切换单元,还用于在预定时间内达成共识的节点未接收到未达成共识的节点的数据确认时,或在预定时间内任一所述节点未接收到其他节点发送的数据确认时,触发所述分布式系统的节点继续切换到所述第二共识模式;
其中,所述数据确认,为各所述节点在切换到所述第二共识模式的准备阶段,将各所述节点持久化存储的消息的哈希值与其他节点持久化存储的消息的哈希值比较并在确认一致时发送,且携带相应节点的数字签名。
第七方面,本发明实施例提供一种存储介质,存储有可执行指令,用于执行本发明实施例提供的消息处理方法。
本发明实施例具有这样的有益效果:
1)采用数字签名的方式保证通信的可靠性:对于任意通信的双方均采用数字签名的方式,即发送方在发送消息时会携带消息的数字签名例如,使用发送方的不对称加密算法的私钥对消息的摘要进行加密,形成发送方的数字签名,接收方通过验证数字签名确保消息的可靠性,即读消息的签名使用不对称加密算法的公钥(保证接收方和发送方使用相同的不对称加密算法,则接收方预先获知公钥)进行解密,对解密得到的摘要与从消息中提取的摘要比对,如果一致说明数字签名验证通过,发送方发送的消息是可靠的。
2)从节点在接收主节点发送的消息时,会直接向客户端返回结果,在结果中携带必要的信息如唯一性字段、消息序列号和数字签名等,这样,客户端可以直接根据从节点返回的结果来判定从节点达成共识的情况,能够容易地检测出异常节点。
附图说明
图1是本发明实施例提供的分布式系统100应用于区块链系统的一个可选的结构示意图;
图2是本发明实施例提供的区块结构一个可选的示意图;
图3-1是本发明实施例提供的节点200的一个可选的软硬件结构示意图;
图3-2是本发明实施例提供的客户端300的一个可选的软硬件结构示意图;
图4是本发明实施例提供的在第一共识模式中各节点执行选举操作而确定主节点和从节点的一个可选的示意图;
图5是本发明实施例提供的分布式系统的节点在第一共识模式中达成共识、并检测故障节点和恶意节点的一个可选的流程示意图;
图6是本发明实施例提供分布式系统在第一共识模式和第二模式中进行切换的一个可选的流程示意图;
图7是本发明实施例提供分布式系统在第一共识模式和第二模式中进行切换的一个可选的流程示意图;
图8是发明实施例提供的区块链系统采用RAFT算法达成共识的一个可选的流程示意图;
图9是发明实施例提供的区块链系统采用PBFT算法达成共识的一个可选的流程示意图;
图10是本发明实施例提供的实现自适应共识算法运行状态图;
图11是本发明实施例提供的T-RAFT算法共识的实现示意图;
图12是本发明实施例提供的在PBFT算法切换的准备阶段进行切换回T-RAFT算法的一个可选的流程示意图;
图13是本发明实施例提供的区块链系统从T-RAFT算法共识切换到PBFT算法共识的一个可选的流程示意图;
图14是本发明实施例提供的区块链系统PBFT算法共识模式切换到T-RAFT算法共识模式的一个可选的流程示意图;
图15是本发明实施例提供的分布式系统应用于联盟链系统的一个可选的场景示意图。
具体实施方式
以下结合附图及实施例,对本发明进行进一步详细说明。应当理解,此处所提供的实施例仅仅用以解释本发明,并不用于限定本发明。另外,以下所提供的实施例是用于实施本发明的部分实施例,而非提供实施本发明的全部实施例,在不冲突的情况下,本发明实施例记载的技术方案可以任意组合的方式实施。
1)分布式系统,由多个节点通过网络通信而连接形成的系统;还包括客户端,消息的具体内容根据实际的业务场景而有区别,例如,消息可以为交易记录、供节点的状态机执行的指令等。
2)共识,在分布式系统中,节点对其他节点发送的消息的正确性进行验证,如验证成功则向发送消息的节点发送确认,并将该消息进行持久化存储,以用于支持后续进行查询。
例如,在区块链系统中,节点对其他节点提交的新区块的有效性进行验证,如验证成功则向发送新区块的节点发送确认,并将该新区块添加到相应节点所存储的区块链的尾部。
3)共识模式,也称为共识算法,用于保证分布式系统的节点达成共识的算法,例如,包括:
能够实现较高的共识效率、并且能够检测到节点故障或者拜占庭问题(一方向另一方发送消息,另一方没有收到,或者收到了错误的信息的情况)、但是无法解决拜占庭问题的共识模式,本文中也称为第一共识模式,例如,包括Paxos算法;递归容错算法(RAFT,Recursive Algorithm for Fault Tolerance);
用于解决拜占庭问题的共识模式,本文中也称为第二共识模式,例如,包括:
拜占庭容错(BFT,Byzantine Fault Tolerance)算法、实用拜占庭容错(PBFT,Practical Byzantine Fault Tolerance)算法、递归容错算法-拜占庭容错(BFT-RAFT,Byzantine Fault Tolerance Recursive Algorithm for Fault Tolerance)、拜占庭容错(BFT-Paxos)算法等。
4)共识模式切换,也称为共识模式自适应,分布式网络的节点共识算法在网络环境良好的时候自动采用共识效率高可以检测到异常节点(如拜占庭问题的节点)的共识算法,当发现恶意节点或者节点错误的时候,可以自动切换到以支持解决拜占庭容错的共识算法。
本发明实施例涉及的分布式系统是由客户端、多个节点(接入网络中的任意形式的计算设备,如服务器、用户终端)通过网络通信的形式连接形成。
以分布式系统为区块链系统为例,参见图1,图1是本发明实施例提供的分布式系统100应用于区块链系统的一个可选的结构示意图,由多个节点(接入网络中的任意形式的计算设备,如服务器、用户终端)和客户端形成,节点之间形成组成的点对点(P2P,Peer To Peer)网络,P2P协议是一个运行在传输控制协议(TCP,Transmission Control Protocol)协议之上的应用层协议。
参见图1示出的区块链系统中各节点的功能,涉及的功能包括:
1)路由,节点具有的基本功能,用于支持节点之间的通信。
节点除具有路由功能外,还可以具有以下功能:
2)应用,用于部署在区块链中,根据实际业务需求而实现特定业务,记录实现功能相关的数据形成记录数据,在记录数据中携带数字签名以表示任务数据的来源,将记录数据发送到区块链系统中的其他节点,供其他节点在验证记录数据来源以及完整性成功时,将记录数据添加到临时区块中。
例如,应用实现的业务包括:
2.1)钱包,用于提供进行电子货币的交易的功能,包括发起交易(即,将当前交易的交易记录发送给区块链系统中的其他节点,其他节点验证成功后,作为承认交易有效的响应,将交易的记录数据存入区块链的临时区块中;当然,钱包还支持查询电子货币地址中剩余的电子货币;
2.2)共享账本,用于提供账目数据的存储、查询和修改等操作的功能,将对账目数据的操作的记录数据发送到区块链系统中的其他节点,其他节点验证有效后,作为承认账目数据有效的响应,将记录数据存入临时区块中,还可以向发起操作的节点发送确认。
2.3)智能合约,计算机化的协议,可以执行某个合约的条款,通过部署在共享账本上的用于在满足一定条件时而执行的代码实现,根据实际的业务需求代码用于完成自动化的交易,例如查询买家所购买商品的物流状态,在买家签收货物后将买家的电子货币转移到商户的地址;当然,智能合约不仅限于执行用于交易的合约,还可以执行对接收的信息进行处理的合约。
3)区块链,包括一系列按照产生的先后时间顺序相互接续的区块(Block),新区块一旦加入到区块链中就不会再被移除,区块中记录了区块链系统中节点提交的记录数据。
参见图2,图2是本发明实施例提供的区块结构(Block Structure)一个可选的示意图,每个区块中包括本区块存储交易记录的哈希值(本区块的哈希值)、以及前一区块的哈希值,各区块通过哈希值连接形成区块链。另外,区块中还可以包括有区块生成时的时间戳等信息。
在分布式系统中,任何机器如服务器、终端都可以加入而成为节点,在硬件层面上,示例性地,参见图3-1,图3-1是本发明实施例提供的节点200的一个可选的软硬件结构示意图,节点200包括硬件层、中间层、操作系统层和应用层。然而,本领域的技术人员应当理解,图3-1示出的节点200的结构仅为示例,并不构成对节点200结构的限定。例如,节点200可以根据实施需要设置较图3-1更多的组件,或者根据实施需要省略设置部分组件。
节点200的硬件层包括处理器210输入/输出接口240,存储介质230以及网络接口220,组件可以经系统总线连接通信。
处理器210可以采用中央处理器(CPU)、微处理器(MCU,Microcontroller Unit)、专用集成电路(ASIC,Application Specific Integrated Circuit)或逻辑可编程门阵列(FPGA,Field-Programmable Gate Array)实现。
输入/输出接口240可以采用如显示屏、触摸屏、扬声器等输入/输出器件实现。
存储介质230可以采用闪存、硬盘、光盘等非易失性存储介质实现,也可以采用双倍率(DDR,Double Data Rate)动态缓存等易失性存储介质实现,其中存储有用以执行上述通信状态处理方法的可执行指令。
网络接口220向处理器210提供外部数据如异地设置的存储介质230的访问能力,示例性地,网络接口220可以实现如基于码分多址(CDMA,Code Division Multiple Access)、宽带码分多址(WCDMA,Wideband Code Division Multiple Access)等通信制式及其演进制式的通信。
驱动层包括用于供操作系统260识别硬件层并与硬件层各组件通信的中间件250,例如可以为针对硬件层的各组件的驱动程序的集合。
操作系统260用于提供面向用户的图形界面,显示基于区块链的各种应用处理的各种中间结果和最终结果。
应用层包括用于实现节点之间形成共识的共识机制270(用于在第一共识模式和第二共识模式中自适应切换)、以及节点基于分布式系统实现的功能如电子货币钱包280、智能合约290等,包括前述的第一共识模式和第二共识模式。
就应用层举例来说,参见图3-1,图3-1提供的节点的应用层的共识机制270包括:
选举单元2701,用于在第一共识模式中新的共识周期到达时,分布式系统中的节点通过执行选举操作处于主节点的状态或处于从节点的状态;其中,
主节点单元2702,用于当节点处于主节点的状态时接收客户端的消息,验证消息的数字签名,将消息发送到从节点;
从节点单元2703,用于当节点处于从节点的状态时,接收到主节点发送的消息并向客户端返回结果,验证所接收的消息的数字签名后向主节点发送确认接收通知;
主节点单元2702,用于当节点处于主节点的状态时,接收到超出预定数量的从节点的确认接收通知,验证确认接收消息的数字签名后持久化存储消息,向从节点发送存储消息通知;
从节点单元2703,用于当节点处于从节点的状态时,验证所接收的存储消息通知的数字签名后持久化存储所接收的消息;消息用于供客户端确定异常节点。
在一个实施例中,从节点向客户端返回结果携带消息的唯一性字段和从节点的数字签名,用于供客户端验证所接收结果的数字签名后,将所接收结果包括唯一性字段与所发送消息的唯一性字段比较,确定不一致的唯一性字段对应的从节点为出错节点,以及确定未返回相应结果的从节点为故障节点。
在一个实施例中,从节点所返回的结果还携带从节点所接收消息的序列号,用于供客户端根据所接收结果携带的序列号与所发送消息的序列号比较,当发送不一致序列号的从节点的数量超出不一致数量阈值时,判定主节点为恶意节点。
在一个实施例中,还包括切换单元2704,用于在客户端确定主节点为恶意节点,或者,确定从节点中存在故障节点时,切换到第二共识模式
在一个实施例中,切换单元2704,还用于在切换到第二共识模式的准备阶段,将节点持久化存储的消息的哈希值与其他节点持久化存储的消息的哈希值比较,确认一致时向客户端发送携带相应节点的数字签名的一致性确认;
一致性确认,用于供客户端在预定时间内接收到全部节点的一致性确认时,通知全部节点继续切换到第一共识模式;未在预定时间内接收到全部节点的一致性确认时,通知全部节点继续切换到第二共识模式。
在一个实施例中,切换单元2704,还用于在切换到第二共识模式的准备阶段,将节点持久化存储的消息的哈希值与其他节点持久化存储的消息的哈希值比较,确认一致时向消息的发送节点发送携带相应节点的数字签名的数据确认;
数据确认,用于供客户端在预定时间内达成共识的节点未接收到未达成共识的节点的数据确认时,或在预定时间内任一节点未接收到其他节点发送的数据确认时,触发分布式系统的节点继续切换到第二共识模式。
在一个实施例中,主节点单元2702,还用于当节点处于主节点的状态,并在第二共识模式中统计到与从节点针对所接收的消息形成共识的次数超过主节点共识次数阈值时,与从节点切换到第一共识模式。
在一个实施例中,主节点单元2702,还用于在第二共识模式中统计到针对所接收的消息形成共识的次数超过主节点共识次数阈值时,向从节点发送切换到第一共识模式的通知,并在接收到全部从节点发送的切换确认时,与从节点保持节点的状态切换到第一共识模式。
在一个实施例中,从节点单元2703,还用于当节点处于从节点的状态,在接收到切换到第一共识模式的通知时,统计到针对所接收的消息形成共识的次数超过从节点共识次数阈值时,向主节点发送切换确认。
在一个实施例中,选举单元2701,还用于当未接收到主节点的心跳信息时,或者,主节点为恶意节点时,通过执行选举操作确定处于主节点的状态或处于从节点的状态。
在一个实施例中,选举单元2701,还用于当在新的共识周期到达、且未接收到其他节点发送的心跳信息时,向其他节点发送选举请求,选举请求携带节点的数字签名,当接收预定数量的其他节点返回的选举确认时,转换为主节点的状态,定期向其他节点发送心跳信息;其中,选举确认为其他节点验证选取请求携带的数字签名后发送;
选举单元2701,还用于当在新的共识周期到达、且接收到其他节点发送的心跳信息时转换为从节点的状态。
在分布式系统中,客户端是硬件以及在硬件上部署的软件环境的结合,基于此,客户端也可以称为客户端设备,用于实现挖矿、管理节点、部署智能合约等功能。
参见图3-2,图3-2是本发明实施例的客户端的一个可选的软硬件结构示意图,客户端300包括硬件层、中间层、操作系统层和应用层。然而,本领域的技术人员应当理解,图3-2示出的客户端300的结构仅为示例,并不构成对客户端300结构的限定。例如,客户端300可以根据实施需要设置较图3-2更多的组件,或者根据实施需要省略设置部分组件。
客户端300的硬件层包括处理器310输入/输出接口340,存储介质330以及网络接口320,组件可以经系统总线连接通信。
处理器310可以采用CPU、MCU、ASIC或FPGA实现。
输入/输出接口340可以采用如显示屏、触摸屏、扬声器等输入/输出器件实现。
存储介质330可以采用闪存、硬盘、光盘等非易失性存储介质实现,也可以采用DDR实现,其中存储有用以执行上述通信状态处理方法的可执行指令。
网络接口320向处理器310提供外部数据如异地设置的存储介质330的访问能力,示例性地,网络接口320可以实现如基于CDMA、WCDMA等通信制式及其演进制式的通信。
驱动层包括用于供操作系统360识别硬件层并与硬件层各组件通信的中间件350,例如可以为针对硬件层的各组件的驱动程序的集合。
操作系统360用于提供面向用户的图形界面,显示基于区块链的各种应用处理的各种中间结果和最终结果。
应用层用于向分布式系统的节点发送消息,使各节点取得针对消息的共识从而持久化存储消息;检测分布式系统中的异常节点,触发节点切换共识模式。
就应用层举例来说,参见图3-2,图3-2提供了客户端300的应用层的功能结构,包括管理节点380、部署智能合约390和共识370。
就共识370举例来说,包括:
通信单元3701,用于向分布式系统的节点中的主节点发送消息,消息携带客户端的数字签名;
其中,数字签名用于供主节点进行验证,并将所接收的消息携带主节点的数字签名,发送给分布式系统中的从节点;
通信单元3701,用于接收从节点在接收到消息时返回的结果;
检测单元3702,用于根据从节点接收到消息时返回的结果,确定异常节点。
在一个实施例中,检测单元3702,还用于验证所接收结果的数字签名后,将所接收结果包括唯一性字段与所发送消息的唯一性字段比较,确定不一致的唯一性字段对应的从节点为出错节点,以及确定未返回相应结果的从节点为故障节点。
在一个实施例中,检测单元3702,还用于根据所接收结果携带的序列号与所发送消息的序列号比较,当发送不一致序列号的从节点的数量超出不一致数量阈值时,判定主节点为恶意节点。
在一个实施例中,还包括:切换单元3703,用于确定主节点为恶意节点,或者,确定从节点中存在故障节点时,触发分布式系统的节点切换到第二共识模式。
在一个实施例中,切换单元3703,还用于在预定时间内接收到全部节点的一致性确认时,通知全部节点返回第一共识模式;未在预定时间内接收到全部节点的一致性确认时,通知全部节点继续切换到第二共识模式;
其中,一致性确认,为各节点在切换到第二共识模式的准备阶段,将各节点持久化存储的消息的哈希值与其他节点持久化存储的消息的哈希值比较,并在确认一致时发送,且携带相应节点的数字签名。
在一个实施例中,切换单元3703,还用于在预定时间内达成共识的节点未接收到未达成共识的节点的数据确认时,或在预定时间内任一节点未接收到其他节点发送的数据确认时,触发分布式系统的节点继续切换到第二共识模式;
其中,数据确认,为各节点在切换到第二共识模式的准备阶段,将各节点持久化存储的消息的哈希值与其他节点持久化存储的消息的哈希值比较并在确认一致时发送,且携带相应节点的数字签名。
本发明实施例提供的分布式系统来说,其中的节点采用第一共识模式中对来自客户端的消息形成共识,第一共识模式能够保证节点形成共识的效率,当然,本发明实施例不排除分布式系统的节点默认采用第二共识模式对来自客户端的消息形成共识。
对在第一共识模式中达成共识的实现方式进行说明,参见图5,图5是本发明实施例提供的分布式系统的节点在第一共识模式中达成共识、并检测故障节点和恶意节点的一个可选的流程示意图,包括以下步骤:
步骤101,分布式系统的多个节点在在第一共识模式中新的共识周期到达时,通过执行选举操作确定主节点的状态、以及处于从节点的状态。
在一个实施例中,分布式系统的节点具有三种类型(也称为状态):竞争节点、主节点和从节点;分布式系统的各个节点启动计时器,在用于形成共识的新的共识周期到达时,各个节点均为竞争节点,各个竞争节点通过执行选取操作而争取转换为主节点(一个分布式系统只有一个合法的主节点),未成为主节点的竞争节点转换为从节点。
对于每个竞争节点,在新的共识周期开始时会检测是否接收到其他节点发送的心跳信息,如果没有接收到,说明当前共识周期内还未产生主节点,则该竞争节点向其他节点发送选举请求,在选取请求中携带发送节点的数字签名,接收节点验证选取请求的数字签名成功后,确定选举请求的可靠性,即向发送节点发送选举确认,当一个节点接收到足够(如预定数量可以为半数的节点)其他节点的选举确认时即转换为主节点,并定期向其他节点发送心跳信息,接收到心跳信息的竞争节点转换为从节点。当在一个共识周期内任意节点都没有接收的到足够数量的选举确认,则开始新的共识周期继续选取操作直至确定主节点和从节点。
以第一共识模式采用RAFT算法为例,参见图4,图4是本发明实施例提供的在第一共识模式中各节点执行选举操作而确定主节点和从节点的一个可选的示意图。
在分布式系统中,任何一个节点在任何一个时刻都处于三种状态之一:主节点、从节点和竞争节点。在分布式系统正常运行的绝大部分时间,分布式系统中会有一个主节点,其他节点都是从节点,由主节点接受客户端的消息。
分布式系统的工作时间分为连续的共识周期,这里也称为任期(Term),每个任期可以是任意时长,任期用连续的整数进行标号。每个任期首先进行主节点选举,选举时,多个竞争节点竞争成为主节点,一旦某个节点成为主节点,其他竞争节点则转变为从节点,成为主节点的节点将在该任期内一致担任主节点,如果该主节点发生故障,其他节点会在新的任期内进行选举。
任何一个任期内都不会有多个主节点(除非有恶意节点伪装为主节点),每个节点都维护着当前任期的计数,每次节点间的之间的通信都包含任期的计数,每个节点在检测到自己维护的任期计数低于其他节点维护的任期计数时,都会更新自己的任期计数为检测到的最高的值。
当前一共识周期的主节点和竞争节点发现自己的任期计数低于别的节点的任期计数时,则立即把自己转换为从节点,从而保证在每个任期内只有一个主节点。
RAFT算法中采用心跳机制触发主节点选举操作,当分布式系统启动时,所有节点初始化为从节点状态,设置任期为0,并启动计时器,计时器超时后,从节点转化为竞争节点,一旦转化为竞争节点,执行以下操作:
步骤1011,增加节点的任期的计数;
步骤1012,启动一个新的计时器;
步骤1013,向其他节点发送选取请求(Request Vote)远程过程调用协议(RPC,Remote Procedure Call Protocol)消息,并等待其他节点回复选举确认。
如果在计时器超时前接收到多数节点的选举确认,则转换为主节点。如果接受到其他节点发送的附加内容为空的附加入口(Append Entries)心跳RPC消息,说明其他节点已经被选为主节点,则转换为从节点。如果计时器超时还没有接受到以上两种信息中的任何一种,则进行新的选举操作。
节点在接受到多数节点的投票成为主节点后,会立即向所有节点发送Append Entries心跳RPC消息,竞争节点收到Append Entries心跳RPC消息后,转换为从节点,选举操作结束。
步骤102,客户端对消息进行数字签名,发送携带数字签名的消息给主节点。
客户端使用自身的私钥对消息的摘要(本发明实施例中不排除使用任意摘要算法从消息中提取摘要)加密,形成数字签名。
步骤103,主节点验证消息的数字签名成功后,在消息中添加主节点的数字签名,将消息发送到从节点。
主节点使用公钥对数字签名解密得到摘要,与采用摘要算法(与客户端使用的摘要算法一致)进行比对,如果一致则说明消息的来源是可靠的,利用主节点的私钥对消息的摘要加密形成主节点的数字签名,在消息中添加主节点的数字签名发送到各个从节点。对于消息携带的客户端的数字签名可以携带也可以不携带;如果主节点比对如果不一致可以丢弃消息并向客户端要求重传。
步骤104,从节点接收到主节点发送的消息后,验证接收的消息的数字签名,验证通过后向主节点发送确认接收通知,并向客户端发送结果。
从节点使用公钥对接收的消息的数字签名解密得到摘要,与采用摘要算法(与主节点使用的摘要算法一致)进行比对,如果一致则说明消息的来源是可靠的,利用从节点的私钥对确认接收通知的摘要加密形成从节点的数字签名,返回主节点。
从节点向客户端发送结果包括两种情况:
1)在当前共识周期内,如果从节点首次接收到主节点发送的消息,则向客户端发送的结果包括:所接收消息的序列号;消息的唯一性字段(消息中的字段,能够区别与其他消息的字段);从节点针对结果的数字签名,利用从节点的私钥对结果的摘要进行加密得到。
2)在当前共识周期内,如果从节点非首次接收到主节点发送的消息,则向客户端发送的结果包括:消息的唯一性字段(消息中的字段,能够区别与其他消息的字段);从节点针对结果的数字签名,利用从节点的私钥对结果的摘要进行加密得到。
步骤105,主节点验证接收到确认接收通知携带的数字签名,当连续接收到预定数量的从节点发送的确认接收通知后,持久化存储消息,向从节点发送存储消息通知。
存储消息通知中携带主节点针对存储消息通知的数字签名,数字签名为使用主节点的私钥对存储消息通知的摘要加密得到。
对于持久化存储而言,主节点将消息以非易失的方式存储,例如,在区块链系统中,接收到客户端提交的交易记录的节点(主节点)将交易记录存储在区块链的新区块中。
步骤106,从节点接收到存储消息通知,验证携带的数字签名成功后,在从节点本地持久化存储消息,并向主节点发送携带数字签名的存储消息确认。
从节点使用公钥对接收的存储消息通知的数字签名解密得到摘要,与采用摘要算法(与主节点使用的摘要算法一致)进行比对,如果一致则说明存储消息通知的来源是可靠的,利用从节点的私钥对存储消息确认的摘要加密形成从节点的数字签名,将携带数字签名的存储消息确认返回主节点。
步骤107,主节点对接收的存储消息确认的数字签名进行验证,如果接收到超过半数的从节点的存储消息确认并成功验证数字签名,向客户端发送存储消息确认。
主节点向客户端发送的存储消息确认中携带主节点的数字签名,用于供客户端验证存储消息来源的可靠性。
步骤108,客户端主节点和从节点接收到消息时返回的结果,检测异常节点:确定主节点是否为恶意节点,以及,确定从节点中是否存在故障节点。
在一个实施例中,客户端验证各个从节点返回的结果(各个从节点在接收到主节点发送的消息后发)的数字签名成功后,将所接收结果包括唯一性字段与所发送消息的唯一性字段比较,如果不一致,则判定发送不一致的唯一性字段的从节点为出错节点,对于没有返回结果的从节点则判定为故障节点。
在一个实施例中,当主节点为在一个新的共识周期内新产生的主节点时,当接收该主节点发送的消息时,从节点向客户端发送的结果除了包括唯一性字段和数字签名,还包括所接收消息的序列号,从而,客户端能够根据所接收结果携带的序列号与所发送消息的序列号比较,当发送不一致序列号的从节点的数量超出数量阈值时,说明新产生的主节点向从节点发送了伪造的消息,因此判定主节点为恶意节点。
从上述步骤可以看出,在第一共识模式中:
1)采用数字签名的方式保证通信的可靠性:
对于任意通信的双方均采用数字签名的方式,即发送方在发送消息时会携带消息的数字签名例如,使用发送方的不对称加密算法的私钥对消息的摘要进行加密,形成发送方的数字签名,接收方通过验证数字签名确保消息的可靠性,即读消息的签名使用不对称加密算法的公钥(保证接收方和发送方使用相同的不对称加密算法,则接收方预先获知公钥)进行解密,对解密得到的摘要与从消息中提取的摘要比对,如果一致说明数字签名验证通过,发送方发送的消息是可靠的。
2)从节点在接收主节点发送的消息时,会直接向客户端返回结果,在结果中携带必要的信息如唯一性字段、消息序列号和数字签名等,这样,客户端可以直接根据从节点返回的结果来判定从节点达成共识的情况,能够容易地检测出异常节点。
在第一共识模式中检测到异常节点的情况,由于第一共识模式适用于保证节点的共识效率,而对节点异常的容错形能有限,为此,本发明实施例提供在分布式系统中出现异常节点时使分布式系统切换到具有较佳容错性能的第二共识模式的方案。
参见图6,图6是本发明实施例提供分布式系统在第一共识模式和第二模式中进行切换的一个可选的流程示意图,包括以下步骤:
步骤109,客户端确定分布式系统中存在异常节点时,触发分布式系统中的节点从切换到第二共识模式。
当主节点为恶意节点、从节点中存在故障节点、或从节点中存在异常节点时,客户端向分布式系统的节点广播切换到第二共识模式的通知。
步骤110,分布式系统的节点在切换到第二共识模式的准备阶段中,向其他节点发送相应节点持久化存储的消息的哈希值以及数字签名。
步骤111,消息的接收节点接收到分布式系统中全部其他节点(即,除接收节点之外的全部节点)发送的哈希值以及数字签名,验证哈希值的数字签名成功后,将哈希值与接收节点持久化存储的消息的哈希值进行比较,如果全部一致,则向客户端发送一致性确认。
例如,分布式系统中接收到通知的节点1,在向第二共识模式切换的准备阶段,将节点中持久化存储的消息的哈希值以及数字签名发送(如广播)到节点2-N(N为分布式系统中节点的数量),同时,节点1会接收节点2至节点N发送的哈希值,哈希值中携带相应节点的数字签名,节点1验证数字签名成功后,将节点2至节点N发送的哈希值与节点1持久化存储的消息的哈希值进行比较,如果全部一致,则节点1向客户端发送一致性确认。
对于节点2至节点N来讲,接收到哈希值的处理与节点1类似,不再重复说明。
步骤112,客户端检测是否接收到全部节点的一致性确认,如果是,则通知分布式系统的节点继续切换到第一共识模式;如果否,则通知分布式系统的节点继续切换到第二共识模式。
如果客户端接收分布式系统中全部节点发送的一致性确认,说明之前检测到异常节点是由于网络波动或者丢弃响应消息导致的,分布式系统中不存在异常节点,因此重新切换到第一共识模式,保证节点之间达成共识的效率。
如果客户端没有在预定时间内接收分布式系统中全部节点发送的一致性确认,则说明分布式系统中确实存在异常节点,则通知分布式系统中节点继续保持向第二共识模式的切换。
参见图7,图7是本发明实施例提供分布式系统在第一共识模式和第二模式中进行切换的一个可选的流程示意图,包括以下步骤:
步骤109,客户端确定分布式系统中存在异常节点时,触发分布式系统中的节点从切换到第二共识模式。
当主节点为恶意节点、从节点中存在故障节点、或从节点中存在异常节点时,客户端向分布式系统的节点广播切换到第二共识模式的通知。
步骤110,分布式系统的节点在切换到第二共识模式的准备阶段中,向其他节点发送相应节点持久化存储的消息的哈希值以及数字签名。
步骤113,消息的接收节点接收到分布式系统中其他节点发送的哈希值以及数字签名,验证哈希值的数字签名成功后,将哈希值与接收节点持久化存储的消息的哈希值进行比较,如果一致,则向消息的发送节点发送数据确认。
例如,分布式系统中接收到通知的节点1,在向第二共识模式切换的准备阶段,将节点中持久化存储的消息的哈希值以及数字签名发送(如广播)到节点2-N(N为分布式系统中节点的数量),同时,节点1会接收节点2至节点N发送的哈希值,哈希值中携带相应节点的数字签名,节点1验证数字签名成功后,将节点2至节点N发送的哈希值与节点1持久化存储的消息的哈希值进行比较,如果全部一致,则节点1向节点2至节点N分别发送数据确认。
对于节点2至节点N来讲,接收到哈希值的处理与节点1类似,不再重复说明。
步骤114,客户端根据各节点发送的数据确认触发分布式系统的节点返回第一共识模式,或,触发分布式系统的节点继续切换到第二共识模式。
对于分布式系统的各节点,将节点持久化存储的消息的哈希值以及发送节点的数字签名广播到其他节点;对于哈希值的接收节点来说,在验证所接收的哈希值的数字签名后,将所接收的哈希值的与接收节点存储消息的哈希值进行比较,在比较一致时向相应哈希值的发送节点发送数据确认,表示二个节点存储的消息是一致的。
这里涉及到两种情况:
情况1)在预定时间内,对于数据确认的接收节点来说,如果均接收到全部其他节点(除接收节点之外的节点)的发送的数据确认,则可以向客户端发送数据确认,客户端根据数据确认确认得知各节点存储的消息是一致的,没有必要继续切换到第二共识模式,因此可以向分布式系统的各节点发送返回第一共识模式的通知,向第二共识模式切换的过程终止。
例如,节点1向节点2至节点N发送的哈希值,哈希值携带节点1的数字签名,节点2至节点N-1在验证节点1的数字签名成功后,以节点2为例,节点2将节点2持久化存储的消息的哈希值(对于区块链系统中的节点来说,可以为区块链中的最新的区块的哈希值)与节点1发送的哈希值比较,如果一致则向节点1发送数据确认,对于节点3至节点N-1的处理与节点2类似。
假设节点1接收到节点2至节点N-1的数据确认,但是没有接收到节点N的数据确认,由于客户端在预定时间内没有接收到节点1的数据确认,客户端认为节点1未取得与全部其他节点的数据一致,则通知节点1至节点N继续切换到第二共识模式的操作。
情况2)在预定时间内任一节点未接收到全部其他节点的数据确认时,或者,在预定时间内达成共识的节点未接收到未达成共识的节点的数据确认,导致客户端未接收全部其他节点的数据确认,则客户端通知分布式系统的节点继续切换到第二共识模式。
例如,节点1向节点2至节点N发送的哈希值,哈希值携带节点1的数字签名,节点2至节点N-1在验证节点1的数字签名成功后,以节点2为例,节点2将节点2持久化存储的消息的哈希值(对于区块链系统中的节点来说,可以为区块链中的最新的区块的哈希值)与节点1发送的哈希值比较,如果一致则向节点1发送数据确认,对于节点3至节点N-1的处理与节点2类似。
假设节点1在预定时间内接收到节点2至节点N-1的数据确认,但是没有接收到节点N的数据确认,向客户端发送在预定时间内没有接收到全部节点数据确认的通知,客户端通知节点1至节点N继续切换到第二共识模式的操作。
再例如,节点1向节点2至节点N发送的哈希值,哈希值携带节点1的数字签名,节点2至节点N-1在验证节点1的数字签名成功后,以节点2为例,节点2将节点2持久化存储的消息的哈希值(对于区块链系统中的节点来说,可以为区块链中的最新的区块的哈希值)与节点1发送的哈希值比较,如果一致则向节点1发送数据确认,对于节点3至节点N-1的处理与节点2类似。
假设节点1在预定时间内接收到节点2至节点N-1的数据确认,但是没有接收到节点N的数据确认,则节点1向客户端发送未接收到全部其他节点(也就是分布式系统中除节点1的之外节点)的数据确认的通知,客户端通知节点1至节点N继续切换到第二共识模式的操作。
继续对分布式系统的节点切换到第二共识模式,并从第二共识模式切换的回第一共识模式的方式进行说明,对于从第二共识模式切换回第一共识模式,存在这样的几种方式:
方式1)主节点统计到形成共识的次数超出主节点共识次数阈值时,触发从节点切换回第一共识模式,主节点和从节点在切换到第一共识模式中时继承在第二共识模式中的节点状态(即节点作为主节点或从节点的状态保持不变)。
分布式系统处于第二共识模式中时,对于分布式系统中主节点(可以理解地,这里的主节点是针对一个共识周期而言)来说,如果主节点在第二共识模式中统计到与从节点针对所接收的消息达成共识的次数超过主节点共识次数阈值(如M次,M为根据对分布式系统中节点的共识的精度设定,一般地,精度要求越高,则预定次数越大),说明主节点与从节点针对连续来自客户端的消息已经达成较好的共识,为了进一步提升分布式系统的节点达成共识的效率,可以向从节点发送切换到第一共识模式的通知。
对于分布式系统中的从节点,在接收到主节点发送的切换到第一共识模式的通知后,即向主节点发送切换确认(承认主节点在切换到第一共识模式中时可以继续保持主节点的状态),主节点与从节为保持当前节点的状态切换到第一共识模式,这样在第一共识模式中可以避免恶意节点成为主节点的情况,确保共识的效率。
可以理解地,上述的共识节点数量阈值可以为分布式系统中的全部从节点的数量,或者,为分布式系统中在第一共识模式中要求达成共识的从节点的数量的最小值(即第一共识模式的容错性能所要求的共识节点数量的最小值,低于该最小值后第一共识模式中达成的共识的可靠性无法得到保证)。
同理,上述的共识节点比例阈值可以对应分布式系统中的全部从节点的数量即100%,或者,为分布式系统中在第一共识模式中要求达成共识的从节点的数量的最小值如51%(即第一共识模式的容错性能所要求的共识节点数量的最小值,低于该最小值后第一共识模式中达成的共识的可靠性无法得到保证)。
例如,分布式系统在第二共识机制中,假设节点1为主节点,节点2至节点N为从节点,各节点就来自客户端的消息达成的共识进行计数,对于节点1来说,如果节点1与节点2至节点N就最近来自客户端的M个(主节点共识次数阈值)消息均达成共识,说明各节点之间已经达成较好的共识,节点1会向节点2至节点N广播切换到第一共识模式的通知,节点2至节点N向节点1发送切换确认,承认节点1在第一共识模式中仍然为主节点,节点2至节点2N继续作为从节点,即使节点2至节点N中出现恶意节点,也无法伪造来自客户端的消息,确保节点达成共识的效率。
方式2)主节点统计到形成共识的次数超出主节点共识次数阈值,主节点触发从节点切换回第一共识模式,当从节点统计到形成共识次数阈值超出从节点共识次数阈值时,从节点确认切换回第一共识模式,主节点和从节点在切换到第一共识模式中时继承在第二共识模式中的节点状态(即节点作为主节点或从节点的状态保持不变)。
分布式系统处于第二共识模式中时,主节点统计在第二共识模式中与其他节点(包括主节点和其他从节点)针对来自客户端的消息形成共识的次数,如果形成共识的次数超过从节点共识次数阈值(可以小于或等于主节点共识次数阈值,例如,可以为M/2),则向主节点发送同意主节点在第一共识模式中继续作为主节点的通知,第二共识模式中的从节点在切换到第一共识模式中时继续作为从节点,从而完成了切换到第一共识模式的选举操作,并继续在第一共识模式中针对来自客户端的消息达成共识。这样在第一共识模式中可以避免恶意节点成为主节点的情况,确保共识的效率。
在分布式系统的节点切换到第一共识模式之后,如果在第一共识模式中没有检测到异常节点,则继续保持在第一共识模式,如果在返回第一共识模式后仍然无法取得较好的共识(例如,仍然检测到恶意节点、异常节点或出错节点),则重新切换到第二共识模式。
这里的预定数量/比例可以根据前述说明而理解,不再重复说明。
例如,分布式系统的主节点可以基于计数器在切换到第二共识模式后同步开始计时,在计时时间达到计时时间阈值(如10分钟,仅为举例)后,会触发分布式系统的从节点同步切换回第一共识模式,在第一共识模式中执行选举操作确定新的主节点和从节点;如果在切换到第一共识模式后仍然检测到异常节点,则再次切换回第二共识模式(切换到第一共识模式的方式可以根据前述说明而理解),从而,在利用第二共识模式进行共识以保证分布式系统的容错性能的前提下,最大程度提升分布式系统达成共识的效率。
这里的预定数量/比例可以根据前述说明而理解,不再重复说明。
例如,分布式系统在第二共识机制中,假设节点1为主节点,节点2至节点N为从节点,各节点就来自客户端的消息达成的共识进行计数,对于节点1来说,如果节点1与节点2至节点N就最近来自客户端的M个(主节点共识次数阈值)消息均达成共识,说明各节点之间已经达成较好的共识,节点1会向节点2至节点N广播切换到第一共识模式的通知,对于节点2至节点N来说,以节点2为例,节点2统计在第二共识模式中形成共识的次数,如果超出M/2,则向节点1发送切换确认(确认节点1在切换到第一共识模式中时仍然作为主节点,节点2作为从节点);节点3至节点N的处理与节点2类似,不再重复说明。
当节点1接收到节点2至节点N中每个节点发送的切换确认时,切换到第一共识模式并在第一共识模式中,节点1作为主节点、节点2至节点N作为从节点;如果节点1未接收到节点2至节点N每个节点发送的切换确认,则继续停留在第二共识模式,每间隔M/2次共识节点1继续向节点2至节点N发送且切换到第一共识模式的通知,直至接收到节点2至节点N全部节点的切换确认。
下面,以区块链系统(如维护对单独的个人或实体开放的联盟链系统)在第一共识模式中采用改进的RAFT(T-RAFT)算法,在第二共识模式中采用PBFT算法进行共识为例,可以理解地,第一共识模式中还可以使用Paxos算法,第二共识模式中还可以采用BFT算法、BFT-RAFT等;第一共识模式可以采用任意共识效率高并且能检测到节点故障或者拜占庭节点的算法如T-RAFT算法,第二共识模式可以采用任意可以实现拜占庭容错的算法。
RAFT算法只解决了多个节点数据一致性的问题,并不解决拜占庭容错,但是RAFT算法效率比较高。PBFT算法可以解决拜占庭容错,但是由于在PBFT算法中需要在节点中进行消息广播,实现的效率比较低。
在分布式网络应用到联盟链(对单独的个人或实体开放的区块链)的使用场景中,一般来说,区块链系统在绝大部分时间里是没有节点故障、也没有拜占庭节点问题,采用RAFT的算法可以高效达成节点之间的共识。
只要在有节点出错或者有拜占庭问题的时候,能够自动采用要求PBFT算法实现各节点的共识,当所有节点都完全达成共识即没有拜占庭节点的时候,再自动切换到共识效率较高的RAFT算法实现各节点间的共识。
RAFT解决了多个节点一致性的问题,效率比较高,但是没有解决节点间拜占庭容错的问题。
PBFT算法可以保证多个节点的一致性并且解决了各个节点间拜占庭容错。
参见图8,图8是发明实施例提供的区块链系统采用RAFT算法达成共识的一个可选的流程示意图,客户端发送的消息主节点(leader节点)之后,主节点对接收的消息进行排序,按照排序分发给从节点(follower节点),其他follower按照leader节点组织好的顺序存储消息到日志中,并向leader节点返回RPC结果(result),然后leader节点将日志中消息存储在本地磁盘后,再向各从节点发一次提交(commit),则各从节点将消息中的日志存储在从节点的本地磁盘中,就完成了消息的一致性同步,具有较高的效率,但是不能解决拜占庭节点的问题。
参见图9,图9是发明实施例提供的区块链系统采用PBFT算法达成共识的一个可选的流程示意图,一个消息需要两次广播之后才能真正确认,由于依赖于广播,在达成共识的过程发送的消息数是节点数的平方级别,因此实现共识的效率比较低,但是能解决节点间拜占庭容错的问题。
RAFT算法虽然能解决一致性问题且效率高,但是不能解决拜占庭容错问题,所以在很多区块链系统的场景里是不被采纳,而只能采纳相对低效但是能解决拜占庭容错的PBFT算法。本发明实施例充分利用在联盟链的应用场景的特点:多数情况下网络条件良好且无拜占庭节点,只需要多节点之间实现共识,结合RAFT的高效和PBFT的容错优点,提供了高效并且能解决拜占庭容错问题自适应共识算法。
在应用于联盟链的区块链系统中,参与共识的节点个数有限,并且在绝大多数情况下各个参与节点没有拜占庭节点,只需要保证数据一致性,此时采用效率较高的T-RAFT算法。当出现异常如节点间有拜占庭容错需求或者节点故障的时候,能够及时检测到并且能够自动切换到可以支持拜占庭容错的PBFT算法,当PBFT算法中所有节点都达成共识的时候,再自动切换到效率较高的T-RAFT算法,这样在绝大多数情况即网络良好、无拜占庭节点的时,可以满足联盟链的高效共识的要求,有异常节点的时候又可以实时纠正、容错。
为实现共识算法的自动切换,参见图10,图10是本发明实施例提供的实现自适应共识算法运行状态图,区块链系统默认在T-RAFT算法下共识,T-RAFT算法检测到数据不一致的节点低于阈值(全部节点数量,或预定比例的节点,根据T-RAFT算法的容错性能设定)的时候,进入数据(消息)一致性的确认状态:如果确认各节点的数据一致,再回到T-RAFT算法:如果节点的数据不一致,转为PBFT算法实现节点之间的共识。当PBFT算法运行时检测到所有节点的数据实现一致,再切换到T-RAFT算法。
T-RAFT算法是RAFT算法的改进,能够防止节点篡改、重放、伪造消息,并且能够及时发现恶意节点,参见图11,图11是本发明实施例提供的T-RAFT算法共识的实现示意图,相对于RAFT算法而言,涉及的改进主要涉及以下几个方面:
1、客户端(Client)发送的消息中带有针对消息的消息体的数字签名,这样可以防止消息在传输的过程中被修改,并且消息中携带唯一性字段,可以防止消息被截获后重放。
2、各个节点间之间传输的消息携带发送方的数字签名,消息的接收节点都会验证数字签名的正确性,这样可以防止伪造新节点参与选举操作或伪装成主节点向从节点发送虚假的消息。
3、客户端请求到主节点之后,T-RAFT共识模式中的主节点消息同步给从节点的过程中,所有的从节点收到主节点发送的消息之后,除了完成原RAFT的消息流程之外,都会向客户端返回结果,返回结果中带消息中的唯一性字段以及从节点的数字签名。这样客户端就可以通过比较所有节点返回的结果,是否一致来判断各节点数据(消息)的一致性。如果客户端收到的结果不一致或者预定时间内未收到所有节点的结果,则判断存在拜占庭节点或者存在故障节点,就会触发数据一致性确认的流程。
数据一致性确认的过程发生在共识算法切换的中间阶段,数据修复的过程实际上是一次少数服从多数的共识过程,共识的过程采用消息广播的方式,具体来说,节点默认使用T-RAFT算法;在有节点出错或者有拜占庭节点的时候,客户端通过比较各个节点返回的结果可以发现数据不一致的情况,以判断是否需要进行算法切换。
举例来说,如需要切到PBFT算法的共识模式,客户端向各节点广播切换到PBFT算法的通知所有节点,当节点收到共识算法切换的通知而处于准备(prepare)阶段的时候,广播数据请求确认消息到所有其他的节点,数据请求确认消息携带节点的区块链中最近共识的区块的哈希值以及节点的数字签名
收到数据请求确认消息的节点,这里称为接收节点,会检查节点的区块链中最新的共识的区块的哈希值跟数据请求确认消息携带的哈希值是否一致,并验证节点数字签名的正确性,对于接收节点来说,如果接收到所有其他节点的数据请求确认消息,并且这些数据请求确认消息签名正确、且与接收节点最新共识的区块的哈希值一致,则回复客户端数据一致性确认,其中携带接收节点的数字签名。
如果客户端接收等到所有节点的数据一致性确认,则认为各节点维护的区块链的数据是一致的,并且认为算法切换请求之前的数据一致性比对失败是网络波动或者丢弃响应消息导致的,就会重新切换到到T-RAFT算法。具体流程可以参考如下消息流程图:
作为一个示例,参见图12,图12是本发明实施例提供的在PBFT算法切换的准备阶段进行切换回T-RAFT算法的一个可选的流程示意图,在图12中,节点1、2、3、4都收到了来自其他节点的数据一致性确认的广播消息,并且确认各节点最新共识的区块的哈希值也一致,各节点都向客户端返回数据一致性确认,并且各自返回T-RAFT算法的状态,即使客户端重新切换到T-RAFT的通知没有到达节点,节点在超时时间到达之后也会进入T-RAFT算法的选举流程。
如果在超时时间内客户端没有收到所有节点的数据一致性确认,或者共识节点(即区块链系统中最新的区块的哈希值一致)没有收到其他所有节点数据一致性确认的广播消息,则客户端通知所有节点切换到PBFT算法。
另外,对于任一节点来说,如果没有收到其他所有节点的数据一致性确认的广播消息,会自动进入PBFT算法状态,并广播切换到PBFT算法的通知。
当节点收到f+1个以上的新算法广播消息之后(f为根据PBFT算法在区块链系统中能够允许的出错节点的最大值),开始发起新算法(PBFT)中主节点的选举,也称为视图更换(view change),完成之后进入新的PBFT算法的共识阶段。
参见图13,图13是本发明实施例提供的区块链系统从T-RAFT算法共识切换到PBFT算法共识的一个可选的流程示意图,这个消息流程示意图中,假设节点4故障,节点1、2和3收到客户端的切换算法的通知而处于PBFT算法的切换准备阶段时,分别广播数据请求确认消息,消息中带了自己最新共识的区块块的哈希值,由于4节点故障了,1、2、3节点在超时时间内不会接收到节点4广播的数据一致性确认(一致响应),所以不会向客户端发送数据一致性确认,节点1、2、3和客户端在超时之后,都会广播切换到PBFT算法的通知,节点1、2、3都会收到算法切换的通知,大于f+1,最先收到f+1个算法切换通知的节点首先发起视图更换流程,视图更换完成之后,进入PBFT算法共识模式。
在PBFT的共识中,一旦主节点统计到连续出现M次(可配置)数据完全一致,会转换为T-RAFT的竞争节点,并触发T-RAFT的选举过程,其他节点收到选举请求之后,只要也统计到连续共识的次数大于M/2次或者大于一个固定的配置值T,就会同意竞争节点转换为主节点,只有所有从节点都同意竞争节点转换为主节点时,进入T-RAFT算法的共识模式,各节点的连续共识次数将清零。只要有一个从节点不同意竞争节点转换为主节点,竞争节点马上恢复到原有状态即转换为PBFT算法的主节点,继续执行PBFT算法,各节点的共识统计次数继续累加,直到M+T的时候再次触发一次T-RAFT选举,如果不成功,下一次等到M+2T的时候触发,如此往复,M+x*T的时候触发,x是次数,直到主节点选举成功为止。
参见图14,图14是本发明实施例提供的区块链系统PBFT算法共识模式切换到T-RAFT算法共识模式的一个可选的流程示意图,PBFT算法的过程中,主节点即节点1统计到数据连续一致(共识)超过M次的时候,转变为T-RAFT的竞争节点状态,然后发起T-RAFT算法的选举,节点2、3和4收到选举请求(request vote)消息之后,判断是否也统计到连续数据一致的数量大于M/2(或者一个固定的值T),如果是,则返回同意竞争节点转换为主节点的切换确认。
竞争节点收到2,3,4节点的切换确认,转换成主节点开始T-RAFT算法共识阶段。在T-RAFT选举的过程中,原来PBFT共识模式中的主节点(节点1)收到客户端的消息之后,不再发送定序(PBFT算法中的pre-prepare)消息,等到选举完成,在T-RAFT中将消息附在AppendEntries RPC中发送给从节点。
再结合实际应用中一个使用场景进行说明,参见图15,图15是本发明实施例提供的分布式系统应用于联盟链系统的一个可选的场景示意图,联盟链系统是对单独的个人或实体开放的,包括多个节点,每个节点向第三方支付机构、以及银行业务系统(作为客户端)提供接入,接收第三方支付机构、以及银行业务系统提交的交易记录,节点对提交的一个交易记录形成共识后,才会将该交易记录存储在区块链的最新区块中存储,供第三方支付机构和签约银行根据各自的业务流水进行对账。
节点默认使用T-RAFT共识模式取得针对交易记录的共识,在出现异常节点时切换到PBFT共识模式对交易记录取得共识。
用户的第三方支付终端中绑定了用户在在银行的信用卡账户,用户与商家在线下或线上进行交易时,第三方支付终端可以通过预先获得的信用卡账号的预授权,从用户的信用卡账户中划款到商家的账户,形成一个交易记录。
对于这笔交易来说,第三方支付机构的业务系统会在分布式系统中所接入的主节点提交一个交易记录(例如,包括收款方、付款方和支付金额,携带第三方支付客户端的数字签名);主节点对接收到交易记录验证数字签名成功后,将交易记录同步给其他的从节点(携带主节点的数字签名),从节点验证交易记录的数字签名成功后,一方面向第三方支付机构业务系统返回结果(携带从节点数字签名、唯一性字段,在主节点为新选举出的主节点时,还携带交易记录的序列号);另一方面,通知主节点同步完毕;主节点在确认各从节点同步完成后将交易记录存储在区块链的最新区块中并通知各从节点,从节点执行相同操作,完成交易记录的持久化存储。
对于上述针对交易记录的共识过程,如果客户端根据从节点返回的结果确定主节点为恶意节点,或从节点出现故障,则会触发联盟链系统切换到PBFT共识模式取得针对交易记录的共识,确保交易记录能够在各节点的区块链中顺利存储;根据联盟链系统对第三方支付结构业务系统后续提交的交易记录的共识情况,如取得较好的公式(主节点与其他节点连续M次共识),可以切换回T-RAFT共识模式以提升共识的效率。
综上,本发明实施例具有以下有益效果:
1)客户端与节点之间、节点之间采用数字签名的方式保证通信的可靠性,避免消息伪装的情况,保证分布式系统内部通信的可靠性。
2)从节点在接收主节点发送的消息时,会直接向客户端返回结果,在结果中携带必要的信息如唯一性字段、消息序列号和数字签名等,这样,客户端可以直接根据从节点返回的结果来判定从节点达成共识的情况,能够容易地检测出异常节点。
3)在检测到异常节点时,能够从默认的共识效率高的第一共识模式切换到容错性能更优的第二共识模式,确保分布式系统的共识在出现异常时也能够顺利达成。
4)在第二共识模式中一旦达成较好的共识(例如,根据共识次数判断),则再次切换到第一共识模式,这种自适应的共识模式切换实现了共识效率和容错性能的最佳融合。在分布式系统的运行的网络状态良好的多数时间内、实现了共识效率高的技术效果,节点故障或者有拜占庭容错节点时保真分布式系统的业务功能正常处理。
本领域的技术人员可以理解:实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成,前述的程序可以存储于一计算机可读取存储介质中,该程序在执行时,执行包括上述方法实施例的步骤;而前述的存储介质包括:移动存储通信状态处理装置、随机存取存储器(RAM,Random Access Memory)、只读存储器(ROM,Read-Only Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
或者,本发明上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时,也可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机通信状态处理装置(可以是个人计算机、服务器、或者网络通信状态处理装置等)执行本发明各个实施例所述方法的全部或部分。而前述的存储介质包括:移动存储通信状态处理装置、RAM、ROM、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述,仅为本发明的具体实施方式,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应以所述权利要求的保护范围为准。