CN110535680A - 一种拜占庭容错方法 - Google Patents

一种拜占庭容错方法 Download PDF

Info

Publication number
CN110535680A
CN110535680A CN201910630939.9A CN201910630939A CN110535680A CN 110535680 A CN110535680 A CN 110535680A CN 201910630939 A CN201910630939 A CN 201910630939A CN 110535680 A CN110535680 A CN 110535680A
Authority
CN
China
Prior art keywords
node
replica
message
view
request
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201910630939.9A
Other languages
English (en)
Other versions
CN110535680B (zh
Inventor
张菁菁
吴维刚
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sun Yat Sen University
National Sun Yat Sen University
Original Assignee
National Sun Yat Sen University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by National Sun Yat Sen University filed Critical National Sun Yat Sen University
Priority to CN201910630939.9A priority Critical patent/CN110535680B/zh
Publication of CN110535680A publication Critical patent/CN110535680A/zh
Application granted granted Critical
Publication of CN110535680B publication Critical patent/CN110535680B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/30—Decision processes by autonomous network management units using voting and bidding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/26—Special purpose or proprietary protocols or architectures

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Hardware Redundancy (AREA)

Abstract

本发明公开一种拜占庭容错方法，包括共识协议、视图更换协议和检查点协议三个子协议；共识协议协调副本节点对来自主副本节点的请求执行顺序达成一致；当副本节点无法达成一致时，从副本节点触发视图更换协议，选举新的主副本节点，再次执行共识协议；分布式系统每执行一定数目的请求之后，对副本节点的日志进行周期性清理，副本节点对自身的状态进行更新。该方法在没有错误节点时，能取得良好的性能，在有错误节点的情况下能实现性能的平滑下降，解决了连续视图更换过程中可能出现的节点状态不一致问题，解决某些BFT协议在存在错误节点时，性能严重下降的问题。

Description

一种拜占庭容错方法
技术领域
本发明涉及分布式系统副本管理领域，更具体地，是一种拜占庭容错方法。
背景技术
随着用户量和数据量的持续增长，大部分互联网应用选择部署于公用的网络环境上，比如部署于云平台之上，这使得应用可能成为网络入侵和攻击的目标。在存在攻击和入侵的网络环境中，分布式系统如何保证应用服务及用户数据的高可用和高可靠是工业界和学术界都非常关注的课题。
复制备份(replication)技术是实现高可用和高可靠的基本手段[1]，它通过将数据复制多份，并把数据副本存放于不同的节点上，从而避免单点故障而导致的不可访问/数据丢失。但是，副本节点中可能存在恶意节点，为了抵御存在的恶意副本节点，系统需要使用拜占庭容错算法对数据进行备份管理，以实现容错 (fault tolerance)。拜占庭容错算法能够通过副本管理技术，保证系统中所有非恶意节点上数据副本的一致性，以达到系统高可用性和高可靠性。
分布式网络中的容错问题由Leslie Lamport等在1982年提出，被称为TheByzantine Generals Problem或者Byzantine Failure[2]。拜占庭将军问题描述的是在有叛徒的军队中，如何使忠诚的将军对进攻还是撤退达成一致的问题。引申到计算领域，发展成了一种容错理论。现实中将硬件错误，网络阻塞或断开以及遭到恶意入侵和攻击，计算机可能出现不可预料的行为等抽象为拜占庭将军问题，因此解决拜占庭将军问题具有了现实意义。拜占庭容错方法(Byzantine fault tolerant) 能容忍任何形式的软件错误和安全漏洞，是一种解决分布式系统容错问题的通用方案[3]。拜占庭容错(BFT)协议主要用来对副本节点所执行的请求序列达成一致，即使系统存在拜占庭错误。其他文献证明系统需要至少3f+1个节点来容纳 f错误节点[4]。
最初，拜占庭协议通常具有指数级复杂度[2]，随后，研究者提出了多项式级别的拜占庭协议[5]，极大地降低了拜占庭协议的开销。目前拜占庭容错方法主要分为两大类:基于quorum模式和基于主从模式。在基于quorum的BFT协议[6、7、8]中，副本直接执行收到的请求，并回复客户端，一致性检查由客户端执行。显然，基于quorum的BFT协议在低并发的情况下性能较好高，在并发的情况下冲突严重，而解决冲突又导致性能显著下降。相比较而言，在基于主从的 (leader-based)BFT协议[2、9、10]中，副本执行请求之前，主副本节点需为该请求分配一个序列号，然后从副本节点对该序列号达成一致，最后执行请求并将结果返回给客户端。副本对序号达成一致的过程称为共识。显而易见，高并发下，共识能有效地避免冲突，保证良好性能。但是，共识本身也耗费时间和资源。
研究者提出很多方法来降低共识的开销，比如乐观预执行技术[8、10]，虚拟化技术[11]，利用可信部件等[12、13]。但是，目前很多BFT协议[7、8、14、15]在没有错误节点的情况下能够取得良好性能，但当存在错误节点时，性能严重下降。
发明内容
针对的现有技术中拜占庭协议在存在错误节点时，性能严重下降的问题，本发明提供了一种拜占庭容错方法，
一种拜占庭容错方法，工作于分布式系统下，系统中有3f+1个副本节点，其中至多f个节点是错误节点，f小于系统中所有副本节点的其包括共识协议、视图更换协议和检查点协议三个子协议；
共识协议协调副本节点对来自主副本节点的请求执行顺序达成一致；
当副本节点无法达成一致时，从副本节点触发视图更换协议，选举新的主副本节点，再次执行共识协议，保证共识一定能够达成；
分布式系统每执行一定数目的请求之后，对副本节点的日志进行周期性清理，副本节点对自身的状态进行更新。
每个副本节点上所储存的请求历史包括以下部分：乐观执行历史包含已经执行过但没有提交的请求。最大提交请求指的是该副本最近提交请求对应。提交历史指的是序列号小于最大提交请求序列号，且大于提交检查点所对应的序列号的请求。已提交检查点之后的历史可被删除，对应的历史称为垃圾回收历史。
所述的共识协议中，节点通过信息交流对请求序列达成一致，包括以下步骤：
S1.客户端c发送请求，即request消息给主副本节点；
S2.主副本节点收到有效的客户端request消息之后，将下一个待分配序列号 s分配给该请求，主副本节点广播prepare消息给所有从副本节点；
S3.从副本节点收到prepare消息后检查其完整性和有效性，若通过检查，副本节点会直接执行该请求并发送3f+1个first_reply消息回复客户，同时所有副本节点通过全交互方式来本地提交该请求，广播commit消息；若不通过，不通过检查的副本节点；
S4.所有副本节点将该请求的提交信息通过second_reply消息回复给客户；
S5.客户端接收S3的first_reply消息或S4的second_reply消息并完成请求。
其中客户端完成请求包括以下两种方法：
当客户端收到3f+1个一致的first_reply时，这说明所有的副本节点都正确执行了该请求，客户端可认为请求已完成。由于系统中最多有f个错误副本节点，并且每个请求的完成需要3f+1个回复，又因为任何正确的2f+1个副本节点不会执行同序列号的两个不同请求，所以其他请求不会在该序号下完成。数目3f+1 能够保证该请求在该序号下执行这一事实不会改变，即使是错误的节点也无法更改这一事实；
在有错误节点存在时，本方法要求副本节点在任何场景下都要确定性地回复客户端两次，第一次回复的内容是节点执行请求的结果，第二次回复的内容是节点提交请求的相关信息。当客户端收到至少2f+1个一致的first_reply消息和2f+1 个一致的second_reply消息时，即说明至少有f+1个正确副本节点提交了该请求，并且它们不会再提交同序列号下另外的请求，客户端认为请求完成。系统中共有3f+1个副本节点，其中f为错误副本节点。该请求完成方式下，任何请求的完成至少需要2f+1副本节点来完成该请求的本地提交。任何两个2f+1必相交于一个正确副本节点，而正确的副本节点不会提交同序列号下两个不同的请求。所以数目2f+1是保证了安全性，即请求一旦完成就会存在于日志中，错误副本节点也无法改变这一结果。就完成时间而言，该方式在没有错误节点的情况下，共识协议可以在客户端发出请求的3个消息延迟后完成该请求。
所述的视图更换协议如下：副本节点在一系列的视图中工作，视图指的是当前系统配置。每一个视图包含一个主副本节点和3f个从副本节点。对视图进行连续编号，该视图下主副本节点标识为p，p＝v*mod|3f+1|，其中v代表的是视图编号。当从副本节点发现主副本节点有误或系统运行太慢时，会触发视图更换协议。在视图更换协议中，副本节点需要3个阶段才能开始一个新的视图v+1。
T1：从副本节点a广播pre_viewchange消息，告诉其他副本节点自身怀疑当前主副本节点，想通过视图转换选择新的主副本节点；当从副本节点a收到其他副本节点发来的f+1个pre_viewchange消息时，便确定进入视图更换阶段；
T2：从副本节点a进入视图更换阶段，广播view_change消息给新的主副本节点；
T3：新的主副本节点在收到2f+1个有效的view_change消息后，广播 new_view消息给其他副本节点，其中一个new_view消息内包含2f+1个 view_change消息；
T4：从副本节点收到new_view消息后会根据其包含的view_change消息决定新视图的开始状态；副本节点确定新视图状态后，发送view_confirm消息给其他副本；所有副本节点收到2f+1个一致的view_confirm消息之后，开始处理新视图下的消息。至此，视图更换成功。
系统中的副本节点每执行一个请求，就需要记录相关日志。如果日志得不到及时的清理，就会导致系统资源被大量的日志所占用，影响系统性能及可用性。另一方面，由于拜占庭节点的存在，共识协议并不能保证每一个节点都执行了相同的请求，所以，不同副本节点状态可能不一致。因此，拜占庭系统中设置周期性的检查点协议，将系统中的副本同步到某一个相同的状态。因此，周期性的检查点协议可以定期地处理日志，节约资源，同时及时纠正副本节点状态。
处理日志需要区分哪些日志可以删除的，哪些日志仍需保留。所述的检查点协议具体步骤如下：
副本节点每执行一定数量的请求后，触发检查点协议并将自身提交历史包含在checkpoint消息中发送给所有的其他副本节点；
某一副本节点对接收到2f+1个checkpoint消息，则该checkpoint消息所包含的状态至少在f+1个正确节点上一致，则该副本节点该接收到的checkpoint消息所包含的提交历史进行删除，同时对该部分的日志进行删除，副本节点更新自身状态。
与现有技术相比，本发明技术方案的有益效果是：
(1)本发明提出双回复机制，该机制要求副本节点回复客户两次，一次基于请求回复内容，一次基于请求提交情况。双回复机制的发明降低了副本节点在 normal cases下达成共识所需时间。
(2)本发明要求副本节点在视图更换之前检查所收到消息是否存在冲突，解决了连续视图更换过程中可能出现的节点状态不一致问题。
(3)基于以上两种机制，我们设计出DBFT。该发明在保证正确性的前提下，提高了现有BFT协议的性能，包括延迟、吞吐量和扩展性。
附图说明
图1是本发明提供的拜占庭容错方法的共识协议的流程图；
图2是本发明提供的拜占庭容错方法的视图更换协议的流程图；
图3是实施例2中DBFT、PBFT和Zyzzyva随客户端数目变化，吞吐量变化情况(左：faut-free cases下，右：normal cases下)；
图4是实施例2中DBFT、PBFT和Zyzzyva随客户端数目变化，延时变化情况(左：faut-free cases下，右：normal cases下)。
图5是实施例2中DBFT、PBFT和Zyzzyva随错误副本节点数目变化，性能变化情况(normal cases下)。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，仅用于示例性说明，不能理解为对本专利的限制。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
下面结合附图和实施例对本发明的技术方案做进一步的说明。
实施例1
如图1所示，一种拜占庭容错方法，工作于分布式系统下，系统中有3f+1 个副本节点，其中至多f个节点是错误节点，f小于系统中所有副本节点的其包括共识协议、视图更换协议和检查点协议三个子协议；
共识协议协调副本节点对来自主副本节点的请求执行顺序达成一致；
当副本节点无法达成一致时，从副本节点触发视图更换协议，选举新的主副本节点，再次执行共识协议，保证共识一定能够达成；
分布式系统每执行一定数目的请求之后，对副本节点的日志进行周期性清理，副本节点对自身的状态进行更新。
每个副本节点上所储存的请求历史包括以下部分：乐观执行历史包含已经执行过但没有提交的请求。最大提交请求指的是该副本最近提交请求对应。提交历史指的是序列号小于最大提交请求序列号，且大于提交检查点所对应的序列号的请求。已提交检查点之后的历史可被删除，对应的历史称为垃圾回收历史。
所述的共识协议中，节点通过信息交流对请求序列达成一致，包括以下步骤：
S1.客户端c发送请求，即request消息给主副本节点；
S2.主副本节点收到有效的客户端request消息之后，将下一个待分配序列号 s分配给该请求，主副本节点广播prepare消息给所有从副本节点；
S3.从副本节点收到prepare消息后检查其完整性和有效性，若通过检查，副本节点会直接执行该请求并发送3f+1个first_reply消息回复客户，同时所有副本节点通过全交互方式来本地提交该请求，广播commit消息；若不通过，不通过检查的副本节点；
S4.所有副本节点将该请求的提交信息通过second_reply消息回复给客户；
S5.客户端接收S3的first_reply消息或S4的second_reply消息并完成请求。
其中客户端完成请求包括以下两种方法：
当客户端收到3f+1个一致的first_reply时，这说明所有的副本节点都正确执行了该请求，客户端可认为请求已完成。由于系统中最多有f个错误副本节点，并且每个请求的完成需要3f+1个回复，又因为任何正确的2f+1个副本节点不会执行同序列号的两个不同请求，所以其他请求不会在该序号下完成。数目3f+1 能够保证该请求在该序号下执行这一事实不会改变，即使是错误的节点也无法更改这一事实。
在有错误节点存在时，本方法要求副本节点在任何场景下都要确定性地回复客户端两次，第一次回复的内容是节点执行请求的结果，第二次回复的内容是节点提交请求的相关信息。当客户端收到至少2f+1个一致的first_reply消息和2f+1 个一致的second_reply消息时，即说明至少有f+1个正确副本节点提交了该请求，并且它们不会再提交同序列号下另外的请求，客户端认为请求完成。系统中共有3f+1个副本节点，其中f为错误副本节点。该请求完成方式下，任何请求的完成至少需要2f+1副本节点来完成该请求的本地提交。任何两个2f+1必相交于一个正确副本节点，而正确的副本节点不会提交同序列号下两个不同的请求。所以数目2f+1是保证了安全性，即请求一旦完成就会存在于日志中，错误副本节点也无法改变这一结果。就完成时间而言，该方式在没有错误节点的情况下，共识协议可以在客户端发出请求的3个消息延迟后完成该请求。
所述的视图更换协议如下：副本节点在一系列的视图中工作，视图指的是当前系统配置。每一个视图包含一个主副本节点和3f个从副本节点。对视图进行连续编号，该视图下主副本节点标识为p，p＝v*mod|3f+1|，其中v代表的是视图编号。当从副本节点发现主副本节点有误或系统运行太慢时，会触发视图更换协议。在视图更换协议中，副本节点需要3个阶段才能开始一个新的视图v+1。
T1：从副本节点a广播pre_viewchange消息，告诉其他副本节点自身怀疑当前主副本节点，想通过视图转换选择新的主副本节点；当从副本节点a收到其他副本节点发来的f+1个pre_viewchange消息时，便确定进入视图更换阶段；
T2：从副本节点a进入视图更换阶段，广播view_change消息给新的主副本节点；
T3：新的主副本节点在收到2f+1个有效的view_change消息后，广播 new_view消息给其他副本节点，其中一个new_view消息内包含2f+1个 view_change消息；
T4：从副本节点收到new_view消息后会根据其包含的view_change消息决定新视图的开始状态；副本节点确定新视图状态后，发送view_confirm消息给其他副本；所有副本节点收到2f+1个一致的view_confirm消息之后，开始处理新视图下的消息。至此，视图更换成功。
系统中的副本节点每执行一个请求，就需要记录相关日志。如果日志得不到及时的清理，就会导致系统资源被大量的日志所占用，影响系统性能及可用性。另一方面，由于拜占庭节点的存在，共识协议并不能保证每一个节点都执行了相同的请求，所以，不同副本节点状态可能不一致。因此，拜占庭系统中设置周期性的检查点协议，将系统中的副本同步到某一个相同的状态。因此，周期性的检查点协议可以定期地处理日志，节约资源，同时及时纠正副本节点状态。
处理日志需要区分哪些日志可以删除的，哪些日志仍需保留。所述的检查点协议具体步骤如下：
副本节点每执行一定数量的请求后，触发检查点协议并将自身提交历史包含在checkpoint消息中发送给所有的其他副本节点；
某一副本节点对接收到2f+1个checkpoint消息，则该checkpoint消息所包含的状态至少在f+1个正确节点上一致，则该副本节点该接收到的checkpoint消息所包含的提交历史进行删除，同时对该部分的日志进行删除，副本节点更新自身状态。
实施例2
在具体实施上，我们将提出的性能平滑降级的拜占庭容错方法应用在4-16 台虚拟机上，这些虚拟机使用3.4GHz CPU，Linux 2.6Kernel，并且通过带宽为 100Mbps的局域网相连。我们通过吞吐量和延迟两个指标来评估协议的性能。在没有错误节点即fault-free cases和存在错误节点，即normal cases的场景下都进行了实验。通过和目前较高效的两个BFT协议，PBFT和Zyzzyva进行对比来说明本发明的有效性。
在fault-free cases和normal cases下，我们通过测试系统在服务不同数目的客户端时的吞吐量和延迟变化来评估算法性能，并通过测试不同错误节点数目，节点数目为1-5下，协议性能的变化，来评估算法的容错性。
附图3展示出在不同场景下，随客户端数目变化，不同系统吞吐量的变化。我们可以看出无论是否使用batching技术，DBFT吞吐量较PBFT和Zyzzyva变化平缓，且总能在normal cases下获得较高的吞吐量。附图4展示出在两种场景下，随客户端数目变化，不同系统延迟的变化。我们可以看出延迟变化趋势和吞吐量变化一致。相比其他两个算法，DBFT在normal cases下获得较低的延迟。附图5展示了在normal cases下，随错误节点数目增加，三种协议性能变化。DBFT 吞吐量较其他两个算法高，而延迟较低，所以DBFT具有较好的容错性。
显然，本发明的上述实施例仅仅是为清楚地说明本发明所作的举例，而并非是对本发明的实施方式的限定。对于所属领域的普通技术人员来说，在上述说明的基础上还可以做出其它不同形式的变化或变动。这里无需也无法对所有的实施方式予以穷举。凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明权利要求的保护范围之内。
参考文献：
【1】Michael G.Merideth and Michael K.Reiter.2010.Selected results fromthe latest decade of quorum ystems esearch.In Replication.Springer,185–206.
【2】Lamport L，Shostak R，Pease M.The Byzantine Generals Problem[J].ACMTransactions on Programming Languages and Systems，1982，4(3):382-401.
【3】范捷，易乐天，舒继武.拜占庭系统技术研究综述[J].软件学报，2013(6):1346-1360.
【4】Dolev D，Lynch N A，Pinter S S，et al.Reaching approximate agreementin the presence of faults[J].Journal of the ACM，1986，33(3):499-516.
【5】Castro M，Liskov B.Practical Byzantine fault tolerance[C].Symposiumon Operating Systems Design&Implementation.1999.
【6】Malkhi D，Reiter M K.Byzantine quorum systems[J].DistributedComputing， 1998，11(4):203-213.
【7】Abdelmalek M，Ganger G R，Goodson G R，et al.Fault-scalable Byzantinefault-tolerant services[J].symposium on operating systems principles，2005，39(5): 59-74.
【8】Cowling J A，Myers D S，Liskov B，et al.HQ replication:a hybridquorum protocol for byzantine fault tolerance[C].operating systems design andimplementation，2006:177-190.
【9】Yin J，Martin J，Venkataramani A，et al.Separating agreement fromexecution for byzantine fault tolerant services[J].symposium on operatingsystems principles， 2003，37(5):253-267.
【10】Kotla R，Alvisi L，Dahlin M，et al.Zyzzyva:speculative byzantinefault tolerance[J].symposium on operating systems principles，2007，41(6):45-58.
【11】Duan S，Levitt K N，Meling H，et al.ByzID:Byzantine Fault Tolerancefrom Intrusion Detection[C].symposium on reliable distributed systems，2014:253-264.
【12】Garcia R，Rodrigues R，Preguica N M，et al.Efficient middleware forbyzantine fault tolerant database replication[C].european conference oncomputer systems，2011:107-122.
【13】Liu J，Li W，Karame G O，et al.Scalable Byzantine Consensus viaHardware-Assisted Secret Sharing[J].IEEE Transactions on Computers，2019， 68(1):139-151.
【14】Zielinski P.Low-latency atomic broadcast in the presence ofcontention[C]. international symposium on distributed computing，2006:505-519.
【15】Guerraoui R，N，Quema V，et al.The next 700 BFT protocols[C]. european conference on computer systems，2010:363-376。

Claims (7)

1.一种拜占庭容错方法，工作于分布式系统下，系统中有3f+1个副本节点，其中至多f个节点是错误节点，f小于系统中所有副本节点的其特征在于，包括共识协议、视图更换协议和检查点协议三个子协议；
共识协议协调副本节点对来自主副本节点的请求执行顺序达成一致；
当副本节点无法达成一致时，从副本节点触发视图更换协议，选举新的主副本节点，再次执行共识协议；
分布式系统每执行一定数目的请求之后，将触发检查点协议，检查点协议对副本节点的日志进行周期性清理，副本节点对自身的状态进行更新。
2.根据权利要求1所述的拜占庭容错方法，其特征在于，所述的共识协议的实现包括以下步骤：
S1.客户端c发送请求，即request消息给主副本节点；
S2.主副本节点收到有效的客户端request消息之后，将下一个待分配序列号s分配给该请求，主副本节点广播prepare消息给所有从副本节点；
S3.从副本节点收到prepare消息后检查其完整性和有效性，若通过检查，副本节点会直接执行该请求并发送3f+1个first_reply消息回复客户，同时所有副本节点通过全交互方式来本地提交该请求，广播commit消息；若不通过，删除不通过检查的副本节点；
S4.所有副本节点将该请求的提交信息通过second_reply消息回复给客户；
S5.客户端接收S3的first_reply消息或S4的second_reply消息并完成请求。
3.根据权利要求2所述的拜占庭容错方法，其特征在于，所述的视图更换协议的实现包括以下步骤：
T1：从副本节点a广播pre_viewchange消息，告诉其他副本节点自身怀疑当前主副本节点，需通过视图转换选择新的主副本节点；当从副本节点a收到其他副本节点发来的f+1个pre_viewchange消息时，确定进入视图更换阶段；
T2：从副本节点a进入视图更换阶段，广播view_change消息给新的主副本节点；
T3：新的主副本节点在收到2f+1个有效的view_change消息后，广播new_view消息给其他副本节点，其中一个new_view消息内包含2f+1个view_change消息；
T4：从副本节点收到new_view消息后会根据其包含的view_change消息决定新视图的开始状态；副本节点确定新视图状态后，发送view_confirm消息给其他副本；所有副本节点收到2f+1个一致的view_confirm消息之后，开始处理新视图下的消息。
4.根据权利要求1所述的拜占庭容错方法，其特征在于，所述的检查点协议具体步骤如下：
副本节点每执行一定数量的请求后，触发检查点协议并将自身提交历史包含在checkpoint消息中发送给所有的其他副本节点；
某一副本节点对接收到2f+1个checkpoint消息，则该checkpoint消息所包含的状态至少在f+1个正确节点上一致，则该副本节点该接收到的checkpoint消息所包含的提交历史进行删除，同时对该部分的日志进行删除，副本节点更新自身状态。
5.根据权利要求2所述的拜占庭容错方法，其特征在于，所述的步骤S5中客户端完成请求的方法如下：
当客户端收到3f+1个一致的first_reply时，说明所有的副本节点都正确执行了该请求，客户端认为请求已完成。
6.根据权利要求2所述的拜占庭容错方法，其特征在于，所述的步骤S5中客户端完成请求的方法如下：
当客户端收到至少2f+1个一致的first_reply消息和2f+1个一致的second_reply消息时，即说明至少有f+1个正确副本节点提交了该请求，正确副本节点不会再提交同序列号下另外的请求，客户端认为请求完成。
7.根据权利要求3所述的拜占庭容错方法，其特征在于，所述的视图更换协议中，每个视图包含1个主副本节点和3f个从副本节点，对视图进行连续编号，该视图下主副本节点标识为p，p＝v*mod|3f+1|，其中v代表的是视图编号。
CN201910630939.9A 2019-07-12 2019-07-12 一种拜占庭容错方法 Active CN110535680B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910630939.9A CN110535680B (zh) 2019-07-12 2019-07-12 一种拜占庭容错方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910630939.9A CN110535680B (zh) 2019-07-12 2019-07-12 一种拜占庭容错方法

Publications (2)

Publication Number Publication Date
CN110535680A true CN110535680A (zh) 2019-12-03
CN110535680B CN110535680B (zh) 2020-07-14

Family

ID=68659707

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910630939.9A Active CN110535680B (zh) 2019-07-12 2019-07-12 一种拜占庭容错方法

Country Status (1)

Country Link
CN (1) CN110535680B (zh)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111179087A (zh) * 2019-12-31 2020-05-19 重庆邮电大学 一种基于网格仲裁的联盟链共识方法
CN111338857A (zh) * 2020-02-11 2020-06-26 安徽理工大学 一种拜占庭容错共识协议
CN111510317A (zh) * 2020-03-06 2020-08-07 杜晓楠 弱化dbft中连续多个节点故障导致的延迟的方法、计算机可读存储介质和dbft网络
CN111526216A (zh) * 2020-07-03 2020-08-11 支付宝(杭州)信息技术有限公司 联盟链中的共识方法和系统
CN111614468A (zh) * 2020-05-24 2020-09-01 济南欣格信息科技有限公司 一种区块链共识方法及系统
CN111612455A (zh) * 2020-04-21 2020-09-01 国网江苏省电力有限公司电力科学研究院 一种面向用电信息保护的拜占庭容错联盟链共识方法及其系统、存储介质
CN111629022A (zh) * 2020-03-20 2020-09-04 恒宝股份有限公司 实用性拜占庭容错的节点设置方法
CN111917826A (zh) * 2020-06-23 2020-11-10 海南大学 一种基于区块链知识产权保护的pbft共识算法
CN114244859A (zh) * 2022-02-23 2022-03-25 阿里云计算有限公司 数据处理方法及装置和电子设备

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130036323A1 (en) * 2011-03-28 2013-02-07 Siemens Corporation Fault-tolerant replication architecture
CN108108967A (zh) * 2017-12-29 2018-06-01 山大地纬软件股份有限公司 面向复杂数字资产的多阶段pbft共识系统及方法
CN109600323A (zh) * 2018-11-12 2019-04-09 中山大学 一种拜占庭共识机制

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130036323A1 (en) * 2011-03-28 2013-02-07 Siemens Corporation Fault-tolerant replication architecture
CN108108967A (zh) * 2017-12-29 2018-06-01 山大地纬软件股份有限公司 面向复杂数字资产的多阶段pbft共识系统及方法
CN109600323A (zh) * 2018-11-12 2019-04-09 中山大学 一种拜占庭共识机制

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
RAMAKRISHNA KOTLA等: "Zyzzyva: Speculative Byzantine Fault Tolerance", 《ACM TRANSACTIONS ON COMPUTER SYSTEMS》 *
刘亚辉: "《中国优秀硕士学位论文全文数据库（电子期刊）》", 15 November 2018 *
范捷等: "拜占庭系统技术研究综述", 《软件学报》 *

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111179087A (zh) * 2019-12-31 2020-05-19 重庆邮电大学 一种基于网格仲裁的联盟链共识方法
CN111179087B (zh) * 2019-12-31 2023-07-18 重庆邮电大学 一种基于网格仲裁的联盟链共识方法
CN111338857A (zh) * 2020-02-11 2020-06-26 安徽理工大学 一种拜占庭容错共识协议
CN111510317A (zh) * 2020-03-06 2020-08-07 杜晓楠 弱化dbft中连续多个节点故障导致的延迟的方法、计算机可读存储介质和dbft网络
CN111510317B (zh) * 2020-03-06 2022-08-26 杜晓楠 弱化dbft中连续多个节点故障导致的延迟的方法、计算机可读存储介质和dbft网络
CN111629022A (zh) * 2020-03-20 2020-09-04 恒宝股份有限公司 实用性拜占庭容错的节点设置方法
CN111629022B (zh) * 2020-03-20 2022-05-20 恒宝股份有限公司 实用性拜占庭容错的节点设置方法
CN111612455A (zh) * 2020-04-21 2020-09-01 国网江苏省电力有限公司电力科学研究院 一种面向用电信息保护的拜占庭容错联盟链共识方法及其系统、存储介质
CN111614468B (zh) * 2020-05-24 2022-08-26 济南欣格信息科技有限公司 一种区块链共识方法及系统
CN111614468A (zh) * 2020-05-24 2020-09-01 济南欣格信息科技有限公司 一种区块链共识方法及系统
CN111917826A (zh) * 2020-06-23 2020-11-10 海南大学 一种基于区块链知识产权保护的pbft共识算法
CN111526216A (zh) * 2020-07-03 2020-08-11 支付宝(杭州)信息技术有限公司 联盟链中的共识方法和系统
US11251967B2 (en) 2020-07-03 2022-02-15 Alipay (Hangzhou) Information Technology Co., Ltd. Consensus methods and systems in consortium blockchain
CN114244859A (zh) * 2022-02-23 2022-03-25 阿里云计算有限公司 数据处理方法及装置和电子设备

Also Published As

Publication number Publication date
CN110535680B (zh) 2020-07-14

Similar Documents

Publication Publication Date Title
CN110535680A (zh) 一种拜占庭容错方法
Katta et al. Ravana: Controller fault-tolerance in software-defined networking
Hunt et al. {ZooKeeper}: Wait-free coordination for internet-scale systems
Singh et al. Zeno: Eventually Consistent Byzantine-Fault Tolerance.
US20150161016A1 (en) Method and system of self-managing nodes of a distributed database cluster with a consensus algorithm
CN105830033B (zh) 用于在分布式数据网格中支持持久存储装置版本化和完整性的系统和方法
Nawab et al. Blockplane: A global-scale byzantizing middleware
US20030187927A1 (en) Clustering infrastructure system and method
US11657035B2 (en) Methods, devices and systems for real-time checking of data consistency in a distributed heterogenous storage system
Zhao et al. Sdpaxos: Building efficient semi-decentralized geo-replicated state machines
Gupta et al. Efficient and non-blocking agreement protocols
Fagg et al. Fault tolerant communication library and applications for high performance computing
CN111338857A (zh) 一种拜占庭容错共识协议
Becker Application-transparent fault tolerance in distributed systems
US11522966B2 (en) Methods, devices and systems for non-disruptive upgrades to a replicated state machine in a distributed computing environment
Pedersen et al. An analysis of quorum-based abstractions: A case study using gorums to implement raft
Agrawal et al. A token-based fault-tolerant distributed mutual exclusion algorithm
Limam et al. A self-adaptive conflict resolution with flexible consistency guarantee in the cloud computing
Soundarabai et al. Fault Tolerance Algorithms for Distributed Computing
Sinha et al. Termination detection in cloud
Horttanainen New Production System for Finnish Meteorological Institute
Bahi et al. Reliable parallel programming model for distributed computing environments
Högqvist Consistent key-based routing in decentralized and reconfigurable data services
Campos et al. An Experimental Evaluation of Machine-to-Machine Coordination Middleware: Extended Version
Brasileiro et al. On the design of the Seljuk-Amoeba operating environment

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant