PBFT常见问题：为什么是f+1、2f+1、3f+1？prepare阶段和commit阶段的作用？恶意节点如何作恶？

目录

说明

1、为什么客户端要收到f+1个执行结果相同的reply才能确认？

2、为什么prepare和commit阶段需要2f+1个确认？

3、为什么副本总数是3f+1？

4、能不能去掉prepare阶段？为什么有prepare阶段？

5、能不能去掉commit阶段？为什么有commit阶段？

6、视图变换何时提出？怎样开始？过程如何？

7、视图切换如何进行？恶意副本有没有可能在视图切换时作恶？

8、视图切换后未完成的请求如何继续？

说明

1. 本文是基于PBFT的原文的讲解：https://pmg.csail.mit.edu/papers/osdi99.pdf
2. PBFT中的每一个消息都包含客户端请求消息的摘要，而请求信息又包含客户端的签名，所以消息不能被篡改（原文中讲到“我们假设攻击者和他控制的故障节点的计算能力是有限的以至于他几乎不可能破解前面提到的密码学技术。例如，攻击者不能产生非故障节点的有效签名，也不能通过消息摘要计算出整个消息，也不能找到拥有相同摘要的两个消息。”）。
3. PBFT算法是一种状态机复制，每一个“节点”是一个副本，有一个主副本，其他全为从副本。
4. 算法的目的是：保证正常副本的弱同步（过程不一定全同步，但执行结果和执行顺序同步）
5. 很多地方是个人解读，有错误望指正。

 

1、为什么客户端要收到f+1个执行结果相同的reply才能确认？

        f+1个执行结果相同的reply必定是全部来自正常副本，因为恶意副本只有f个。

2、为什么prepare和commit阶段需要2f+1个确认？

        如果是f+1，可能其中f是恶意副本，伪装经过prepare和commit阶段后，在执行请求时开始作恶，那么客户端就收不到f+1个reply确认。但如果是2f+1，就确保了f+1个正常副本同时开始执行请求。

3、为什么副本总数是3f+1？

        问题2的解答说明副本总数最少是2f+1，在此基础上我们看：因为f恶意副本可能会不发送消息，那么除去这f个恶意副本的消息我们也要达到2f+1的确认。换句话说我们必须有2f+1个正常副本才可以在f个恶意副本拒绝发送消息的情况下顺利进行确认和整个流程。2f+1个正常副本加上f个恶意副本就是3f+1个总副本。

4、能不能去掉prepare阶段？为什么有prepare阶段？

        去掉这两个阶段后如果主副本作恶就无法解决。（prepare阶段用于可在主副本不作为（不发送pre-prepare消息）的情况下提出视图变换）

5、能不能去掉commit阶段？为什么有commit阶段？

        commit阶段用于在切换主节点之后也能继续执行未完成的请求m（若在视图v中副本i以编号n执行了请求m，那么在v+1中未执行请求m的副本j也能以编号n执行请求m）。避免了视图切换后一系列执行到中途的过程从头开始。

6、视图变换何时提出？怎样开始？过程如何？

        主副本在pre-prepare阶段、commit阶段和reply阶段可能会作恶。在pre-prepare阶段和commit阶段作恶会被发现然后被执行视图变换。在reply阶段作恶虽然不会被发现，但并不影响f+1个正常副本的执行。（所有恶意副本通过篡改消息或拒绝通信都不能组织正确副本达成共识。如果恶意主副本拒绝发送pre-prepare请求（所有从副本会根本不知道这一次客户端请求）超过一定时间后，客户端会给所有副本发送自己的请求从而发现主副本的恶意行为）

7、视图切换如何进行？恶意副本有没有可能在视图切换时作恶？

        所有正常副本只要收到f+1个视图切换（view-change）消息，自己便也发出相同的视图切换消息。新的主副本（例如：p’ =（v + 1）mod |R|）收到2f+1个视图切换消息后自己会发出new-view消息。（2f+1是为了确保有最少有f+1个正常节点进入视图变换以成功发出f+1个reply确认，道理同问题2）。故f个恶意副本并不能无中生有发起视图变换。

8、视图切换后未完成的请求如何继续？

        view-change消息中包含了自己的日志，新的主副本通过收集这些日志（尤其是日志中的序列号n，n保证了执行结果顺序的统一）来了解每个请求的执行情况并继续执行。