,m>，广播给其他节点。简而言之就是对请求分配序号并告知所有节点。
【2】 收到PRE-PREPARE的消息后进行如下处理：

消息合法性检查，消息签名是否正确，消息摘要是否正确。 视图检查，检查是否是同一个视图号v。 水线检查，判断n是否在h和H之间。（h一般是系统稳定检查点，H是上限，会随着h的不断提高而提高）

如果都通过的话，就广播PREPARE消息

给其他节点，表示自己收到并认可[n,v]这个请求，进入prepare阶段。如果没有通过，则忽略该消息。
这里想一个问题，从节点能不能收到PRE-PREPARE消息就执行请求呢？答案显然是不能的，因为不能确认本节点与其他节点收到的是相同的请求消息，此时不能确定主节点是不是正常节点，如果主节点是恶意节点呢？比如，发送给从节点1的消息是m，而发送给从节点2的消息是m’，如果直接执行就会出现从节点的不一致。因为不能确认本节点与其他节点收到的是相同的请求消息，所以要通过从节点与从节点交互的方式互相告知收到了请求消息，好让后面阶段对比一下，是否一致。
PREPARE:
收到PREPARE消息

后，进行如下处理：

消息合法性检查，消息签名是否正确，消息摘要是否正确。 视图检查，检查是否是同一个视图号v。 水线检查，判断n是否在h和H之间。

如果上面都通过，就将PREPARE消息加入到日志中，并继续收集PREPARE消息，如果收到正确的2f
张（包括自己）PREPARE消息，这里如何验证是否正确呢？主要是收到的PREPARE要与PRE-PREPARE中的v、n、d等信息要匹配，就进入COMMIT阶段，广播COMMIT消息。
这一阶段一般也可以称为第一轮投票，目的是什么呢？论文中是这么说的：The pre-prepare and prepare phases of the algorithm guarantee that non-faulty replicas agree on a total order for the requests within a view. 浓缩为两个字就是定序，确定在同一视图下足额的正常的节点都对来自客户端的请求有相同的定序。再说的直白点，就是解决上面提到的，无法确认本节点与其他节点收到的消息是否一致的问题。通过检查相同视图号v及同一序号n下的消息摘要d是否一致来判断同一视图配置下的同一个序号请求的消息是否一致。同时也确保了有足够数量的节点收到了一致的消息请求。
可以再想一个问题，此时可以直接执行请求吗？答案是不可以，因为此时，你只能确认自己收到了2f
个一致的PREPARE消息，你无法确认其他节点是否也收到了2f
个一致的PREPARE消息。也就是说，当前，你只能确认自己准备好了去执行序号为n的请求，但是你不能确认其他节点有没有准备好，所以，还要再进行一次节点间的消息交互，互相告诉大家，我准备好了。
COMMIT:
在上一阶段，节点收到足额PREPARE投票后会广播COMMIT投票，过程类似，当节点收到其他节点的COMMIT投票消息后，会进行如下检查：

消息合法性检查，检查消息签名是否正确，消息摘要正不正确有没有被篡改。 视图检查，view是否匹配。 水线检查，判断n是否在h和H之间。

如果都通过则把收到的投票消息写入日志log中，如果收到的合法的COMMIT投票消息大于等于2f+1
个（包括自己），意思就是，已经确认大多数节点都准备好了执行请求，就执行请求并回复REPLY消息给客户端。这里如同上面一样，也是检查视图，序号及消息是否匹配。
REPLY:
客户端收到REPLY后，会进行统计，如果收到f+1
个相同时间戳t和响应值r，则认为请求响应成功。如果在规定的时间内没有收到回应或者没有收到足额回应怎么办？可以将该请求广播给所有节点，节点收到请求后，如果该请求已经被状态机执行了，则再次回复客户端REPLY消息，如果没有被状态机执行，如果节点不是主节点，就将该请求转发给主节点。如果主节点没有正常的将该请求广播给其他节点，则将会被怀疑是主节点故障或恶意节点，当有足够的节点都怀疑时将会触发视图变更协议，更换视图。
我们进行进一步的分析，可以看到，如果是客户端没有收到任何回应，很有可能是主节点故障或主节点是恶意节点（我就故意不执行你的请求），没有将请求足额广播给其他节点，（当然还有消息丢失等原因，这里不在详细分析），这时，客户端因一直没有响应，所以将请求广播给了所有节点，所有节点收到请求后，转发给主节点后发现主节点怎么什么都不干呀，怀疑主节点有问题，然后触发视图更换协议，换掉主节点。当然，客户端没有收到足额回应的一个原因还可能是消息丢失，那么如果是已经执行了该请求的节点再次收到该请求后会再次回应REPLY，前提是该请求是在水线范围内的合法请求，否则被拒绝。
检查点协议
在上面的一致性协议中可以看到，系统每执行一个请求，服务器都需要记录日志（包括，request、pre-prepare、prepare、commit等消息）。如果日志得不到及时的清理，就会导致系统资源被大量的日志所占用，影响系统性能及可用性。另一方面，由于拜占庭节点的存在，一致性协议并不能保证每一台服务器都执行了相同的请求，所以，不同服务器状态可能不一致。例如，某些服务器可能由于网络延时导致从某个序号开始之后的请求都没有执行。因此，设置周期性的检查点协议，将系统中的服务器同步到某一个相同的状态。简言之，主要作用有2个：1、同步服务器的状态；2、定期清理日志。
同步服务器的状态，比较容易理解与做到。比如在区块链系统中，同步服务器的状态，实际上就是追块，即服务器节点会通过链定时广播的链世界状态或其他消息获知到自己区块落后了，然后启动追块流程。
定期清理日志，怎么做呢？首先要明确哪些日志可以被清理，哪些日志仍然需要保留。如果一个请求已经被f+1
台非拜占庭节点执行，并且某一服务器节点i可以向其他服务器节点证明这一点，那么该i节点就可以将关于这个请求的日志删除。协议一般采用的方式是服务器节点每执行一定数量的请求就将自己的状态发送给所有服务器并且执行一个该协议，如果某台服务器节点收到2f+1台服务器节点的状态，那么其中一致的部分就是至少有f+1
台非拜占庭服务器节点经历过的状态，因此，这部分的日志就可以删除，同时更新为较新状态。
具体实现时可以联想到上面的一致性协议总的水线检查。上面的低水线h值等同于稳定检查点，稳定检查点之前的日志都可被清理掉。高水线H=h+k，也就是接收请求序号上限值，因为稳定检查点往往是间隔很多的序号才触发一次，所以k一般要设置的足够大。例如，每间隔100个请求就触发一次检查点协议，提升水线，k可以设置为200。

这里解释一下稳定检查点的概念，可以理解为当2f+1个节点都达到了某个请求序号，该请求序号就是稳定检查点。所有稳定检查点之前的消息都可以被丢弃，减少资源占用。 对比Raft，Raft是通过快照的方式压缩日志，都需要一个清理日志的机制，不然日志无限增长下去会造成系统不可用

视图更换协议
在一致性协议里，已经知道主节点在整个系统中拥有序号分配，请求转发等核心能力，支配着这个系统的运行行为。然而一旦主节点自身发生错误，就可能导致从节点接收到具有相同序号的不同请求，或者同一个请求被分配多个序号等问题，这将直接导致请求不能被正确执行。视图更换协议的作用就是在主节点不能继续履行职责时，将其用一个从节点替换掉，并且保证已经被非拜占庭服务器执行的请求不会被篡改。即，核心有2点：1，主节点故障时，可能造成系统不可用，要更换主节点；2，当主节点是恶意节点时，要更换为诚实节点，不能让作恶节点作为主节点。
当检测到主节点故障或为恶意节点触发视图更换时，下一任主节点应该选谁呢？PBFT的办法是采用“轮流上岗”的方式，通过(v+1) mod N
，其中v为当前视图号，N
为节点总数，通过这一方式确定下一个视图的主节点。还有个更关键的问题，什么时候触发视图更换协议呢？我们继续往下讨论。
如果是主节点故障的情况，这种情况一般较好处理。具体实现时，一般从节点都会维护一个定时器，如果长时间没有收到来自主节点的消息，就会认为主节点发生故障。此时可触发视图更换协议，当然具体实现时，细节可能会不同，比如，也可以是这种情况，客户端发送请求给故障主节点必然导致长时间收不到响应，所以，客户端将请求发送给了系统中所有从节点，从节点将请求转发给主节点并启动定时器，如果主节点长时间没有将该请求分配序号发送PRE-PREPARE消息，认为主节点故障，触发视图更换协议。这2种情况比较好理解，但就这2种情况吗？其实还有以下几种情况也会触发视图更换协议：

从节点广播PREPARE消息后，在约定的时间内未收到来自其他节点的2f

个一致合法消息。
从节点广播COMMIT消息后，在约定的时间内未收到来自其他节点的2f

个一致合法消息。 从节点收到异常消息，比如视图、序号一致，但消息不一致。 这三点，都有可能是主节点作恶导致的，但也有可能是消息丢失等原因导致的。虽然不一定是因为主节点异常导致的，但从另一个角度看，解决了从节点不能无限等待其他节点投票消息的问题。这里补充一点，触发视图更换协议后，将不再接收除检查点消息、VIEW-CHANGE消息、NEW-VIEW消息之外的消息。也就是视图更换期间，不再接收客户端请求，暂停服务。

解决了什么时候触发的问题后，下一个问题就是具体怎么实现呢？当因上面的情况触发视图更换协议时，从节点i就会广播一个VIEW-CHANGE消息，序号n是节点i的最新稳定检查点s，C是2f+1
个有效检查点消息，是为了证明稳定检查点s的正确性，P是位于序号n之后的一系列消息的结合，这里要包含这些信息可以理解为是证据，也就是说，从节点不能随便就发送一个VIEW-CHANGE，什么证据都没有，别人怎么能认同你更换视图呢？。上面我们提到过下一任主节点是谁的问题？通过(v+1) mod N确定的一下任主节点p(在图中就是节点1)，在收到2f
个有效的VIEW-CHANGE消息后，就广播消息，这里V和O具体的生成方法参考原论文，主要是VIEW-CHANGE和PRE-PREPARE等消息构成的集合，主要目的是为了让从节点去验证当前新的主节点的合法性以及解决下面这个问题，还有要处理未确认消息和投票消息。
视图更换协议需要解决的问题是如何保证已经被非拜占庭服务器执行的请求不被更改。由于系统达成一致性之后至少有f+1
台非拜占庭服务器节点执行了请求，所以目前采用的方法是：由新的主节点收集至少2f+1
台服务器节点的状态信息（也就是上面在构造消息时所需的各种消息集合），这些状态信息中一定包含所有执行过的请求；然后，新主节点将这些状态信息发送给所有的服务器，服务器按照相同的原则将在上一个主节点完成的请求同步一遍，同步之后，所有的节点都处于相同的状态，这时就可以开始执行新的请求。
若干细节问题的思考
在3阶段协议中，对收到的消息都要进行消息合法性检查、视图检查、水线检查这3项检查，为什么呢？
这3项检查是十分有必要的，添加消息签名是为了验证投票是否合法，正确统计合法票数，不能是随便一个不知道的节点都能投票，那我怎么验证到底是谁投的呀。也就是说，要通过消息签名的方式确认消息来源，通过消息摘要的方式，确认消息没有被篡改。当然，考虑到性能因素，也可以使用消息认证码（MAC），以节省大量加解密的性能开销。PBFT算法，可以容忍节点作恶，消息丢失、延时、乱序，但消息不能被篡改。
视图检查比较容易理解，所有节点必须在同一个配置下才能正常工作。如果节点的视图配置不一致，比如主节点不一致、节点数量不一致，那统计合法票数的时候，真没法干了。
水线检查，是检查点协议的一部分，在工程实现时，不是所有的请求我都有处理，比如，你收到一个历史投票信息，你还有必要处理吗？当然，它的作用不止于此，还可以防止恶意节点选择一个非常大的序列号而耗尽序列号空间，例如，当一个节点分配了超过H上限的序列号，这时，正常节点会拒绝这个请求从而阻止了恶意节点分配的远超过H的序列号。
3阶段协议中每一阶段的意义是什么？
论文中有如下表述：

The three phases are pre-prepare, prepare, and commit.The pre-prepare and prepare phases are used to totally order requests sent in the same view even when the primary, which proposes the ordering of requests, is faulty. The prepare and commit phases are used to ensure that requests that commit are totally ordered across views.

即，pre-prepare和prepare阶段，主要的作用就是定序，个人理解就是要确认有足够数量的节点收到同一请求，并且与自己所收到的请求相一致。prepare以及commit阶段是确认大家执行的同一请求。
为什么是3f+1
？
我们知道PBFT的容错能力为不超过三分之一，即n=3f+1
，f
为拜占庭节点数量。但这个公式是怎么来的呢？论文中有这么一段论述可以帮助我们去理解：

The resiliency of our algorithm is optimal: 3f+1

is the minimum number of replicas that allow an asynchronous system to provide the safety and liveness properties when up to f replicas are faulty. This many replicas are needed because it must be possible to proceed after communicating with n?f replicas, since f replicas might be faulty and not responding. However, it is possible that the f replicas that did not respond are not faulty and, therefore, f of those that responded might be faulty. Even so, there must still be enough responses that those from non-faulty replicas outnumber those from faulty ones, i.e., n?2f>f. Therefore n>3f

.

意思就是，在一个容忍f
个错误节点的系统中，系统至少要3f+1个节点才能保证系统安全可靠。为什么呢？因为在所有n个节点中，有f个节点可能因故障而没有回应（或者投票），而在回应的n?f中又有可能有f个是恶意节点的回应，即使如此，也要保证正常节点的投票要多于恶意节点的投票数量，即n?f?f>f，推出n>3f
PBFT对比Raft
PBFT对比Raft，最大的不同在于解决的问题不一样，虽然都是共识算法，但一个解决的拜占庭问题，另一个则解决的非拜占庭问题。从算法细节上来看，Raft中的领导者是强领导者，即，一切领导者说了算，但PBFT中对应的主节点却不是，因为不能保证主节点不是拜占庭节点，万一主节点作恶，从节点要有发现主节点是恶意节点的能力，并及时触发视图更换协议更换主节点。从算法消耗的资源来看，明显PBFT要更复杂，投票数明显多于Raft，不但要主从节点交互，还有从节点与从节点互相交互，所以，其性能也一定比Raft低，这是肯定的，因为PBFT解决的问题比Raft更复杂，一定程度上可以认为Raft是PBFT的子集，如果你把PBFT三阶段协议中从节点与从节点交互的那部分去掉，只保留主节点与从节点交互的那部分，你会发现，好像还蛮像的。从另一个方面说，Raft算法，因为没有拜占庭节点的存在，领导者节点一定是对的，从节点一切听领导的就是。但是在PBFT中，从节点就不能光听主节点的，万一主节点也是坏人咋办？怎么解决这个问题呢？显然，只听主节点肯定是不行的，我还要看看其他节点的意见，如果有足额的节点认为是对的，就同意。怎么确定足额节点数到底是多少呢？上面有讲到过。所以，相比Raft，PBFT多了从节点与从节点的消息交互。
PBFT的时间复杂度分析
PBFT有比较明显的两轮投票，所以时间复杂度O(n2)
，节点数量较大时，一次共识协商所需的消息太多，这也决定了PBFT只能适用于节点数量不大的系统中，比如区块链中的许可链，公链节点数量太多，并不适用PBFT算法。

推荐阅读

• 

  外国ios账号，求分享一个美国的apple id谢谢了
• 

  汽车转速表一直在1降不到0还能开吗
• 

  唐山牛年纪念币预约 2023年唐山贺岁纪念币在哪里预约
• 

  云原生应用之旅——Kubernetes成长记 | 第十站（获取云原生旅行秘籍）
• 

  罗汉果几天喝一次最好呢
• 

  不怕水的胶水有哪些
• 

  老黄历：2021年12月9日适合订婚吗,十一月初六这天如何？
• 

  mysql的数据库文件有几种?以及扩展名 mysql数据文件扩展
• 

  麻辣蒜香煎豆腐的制作方法 麻辣蒜香煎豆腐怎么做
• 

  胎压不足指示灯是什么情况? 胎压不足的指示灯
• 

  猪笼草有毒吗?猪笼草养在室内好不好 猪笼草中的水有毒吗
• 

  白面板|如何俘获小姐姐的心？魅族纯白色设计你有必要了解一下
• 

  饺子皮除了包饺子还能做什么好吃的
• 

  能遇见你，真是太好了
• 

  下雪天公交车会停运，公交车下雪天为啥不滑
• 

  怎样设置sim卡密码
• 

  搜狗输入法如何设置显示界面？
• 

  手机大亨2怎么开启x屏幕
• 

  z95
• 

  家公家婆是指什么关系

• web3.eth.accounts undefined
• 阅读比特币白皮书（二）
• 区块链|ethereum和eos的收费模型比较
• web3.py|使用Web3.py连接Ethereum
• blockchain|共识算法-PBFT
• 2018|Base58编码解码Go实现
• 共识算法|拜占庭将军问题的深入思考