1.游戏背景

拜占庭帝国即东罗马帝国，拥有巨大的财富，并对邻邦垂诞已久，为此派出了10支军队去包围这个敌人。这个敌人虽不比拜占庭帝国，但也足以抵御5支常规拜占庭军队的同时袭击。基于一些原因，这10支军队不能集合在一起单点突破，必须在分开的包围状态下同时攻击。他们任一支军队单独进攻都毫无胜算，除非有至少6支军队同时袭击才能攻下敌国。他们分散在敌国的四周，依靠通信兵相互通信来协商进攻意向及进攻时间。困扰这些将军的问题是，他们不确定他们中是否有叛徒，叛徒可能擅自变更进攻意向或者进攻时间。在这种状态下，拜占庭将军们能否找到一种分布式的协议来让他们能够远程协商，从而赢取战斗？这就是著名的拜占庭将军问题【在分布式系统中指的是消息不仅可以被丢失、延迟、重放，还可以被伪造】。

2.游戏介绍

PBFT(Practical Byzantine Fault Tolerance)算法由Miguel Castro 和Barbara Liskov在1999年提出来的，解决了原始拜占庭容错算法效率不高的问题，将算法复杂度由指数级降低到多项式级，使得拜占庭容错算法在实际系统应用中变得可行。

PBFT是一种状态机副本复制算法，一般包括三种协议:一致性协议(agreement)、检查点协议(checkpoint)和视图更换协议(view change)。该算法要满足以下两个性质：

安全性(safety)：safety means nothing bad happens. 活性(liveness)：liveness means that something good eventually happens.

在一个拜占庭系统里面，要容忍f个拜占庭节点错误，则replica数量至少为3f+1，这是满足安全性的前提。因为网络延迟或宕机，系统存在f个节点不回复响应（f个节点包括拜占庭节点和非拜占庭节点，最坏情况f个节点全是非拜占庭节点），剩下2f+1个响应中可能有f个拜占庭节点，从而得到n-2f>f，即响应中非拜占庭节点数目大于拜占庭节点数目（f+1>f）。

算法不依赖同步提供安全性，则必须依赖同步提供活性，否则违背FLP定理(在异步通信场景，即使只有一个进程失败了，没有任何算法能保证非失败进程能够达到一致性)。在拜占庭节点不超过f，并且delay(t)有界的情况下就能保证系统活性，delay(t)表示从消息发送到接受的时间间隔。

3.游戏规则

在一个view里面，会从replicas中选择一个primary，其余的replicas则叫backups。如果主节点行为发生异常，则进行view change换主。

游戏从client向primary发送请求 $<request,\omicron ,t,c>_{sig_{c} }$ 开始。 $\omicron$ 状态机操作， $t$ 时戳。游戏从client至少收到f+1个replicas的响应 $<request,\omicron ,t,c>_{sig_{c} }$ 结束。 $v$ 视图编号， $t$ 时戳， $c$ 客户端身份， $i$ replica编号， $r$ 请求结果。【why f+1？因为在2f+1个committed中有f个拜占庭节点表面上同意请求，实际上根本不会回复请求】

3.1 重彩大戏------三阶段协议

非主节点错误下的PBFT流程

Pre-prepare:

Primary为客户端请求分配一个序列号n，向所有backups发现预准备消息 $<<pre-prepare,v,n,d>_{sig_{p} },m>$ 。 $v$ 视图编号， $d$ 消息 $m$ 的摘要。

Prepare:

若满足以下条件，backups接受预准备消息： 1.客户端请求和预准备消息具有正确签名。 2.当前视图编号是v。 3.backups从未在当前视图v接收过序列号为n但摘要不同的预准备请求。 4.h<n<H。【防止一个拜占庭节点选择一个大的序号来消耗序号空间】

如果上述条件满足，backups接收预准备消息，进入prepare阶段，向其他节点广播准备消息 $<prepare,v,n,d,i>_{sig_{i} }$ ，并将预准备和准备消息写入日志。

commit:

如果backups收到2f【包括自己】个与预准备消息一致的准备消息，请求消息和预准备消息具有相同的视图v和序列号n，并且已将相关消息写入日志，则进入commit阶段，向其他节点广播一条确认消息 $<commit,v,n,d,i>_{sig_{i} }$ 。如果各节点收到2f+1条相同的commits消息，则向客户端发送一条reply消息。

3.2 垃圾回收

PBFT是一种状态机副本复制算法，replicas会将执行过消息记录在本地日志中，为了节省内存，需要一种机制来清理日志。何时来清理？在每次操作完后执行是不明智的，因为比较耗资源。可以定期清理，比如每100次清理一次。我们将请求后执行的状态称为检查点checkpoint；带证明的检查点称为stable certificate，当节点收到2f+1个checkpoint消息时，可证明稳定检查点是正确的。稳定检查点之前的日志消息均可删除。

当清理检查点时replica i向其他replicas广播一条检查点协议 $<checkpoint,n,d,i>_{sig_{i} }$ ， $n$ 是最近一次正确执行请求序号， $d$ 是其当前状态摘要。如果每一个replica收到2f+1个具有相同序号 $n$ 和摘要 $d$ 的检查点消息，这时每一个replica可以清理序列号 $<n,d,v>$ 小于等于n的日志信息。

检查点协议也用来更新水平线。低水平线 $h$ 等于最近稳定检查点的序号，高水平线 $H=h+l$ ， $l$ 为日志大小。

3.3 视图更改

当主节点挂掉，或者在commit阶段有些节点收到2f+1个commit，有些没有收到2f+1个commit，导致状态不一致，这些状况都需要更改视图来提供系统活性和安全性。

当请求超时，备份节点进入视图v+1，广播视图更改消息 $<view-change,v+1,n,C,P,i>$ 。 $n$ 稳定检查点序列号， $C$ 是稳定检查点证明， $P$ 是一个集合，包含对请求 $m$ （请求的序列号大于 $n$ ）相关消息集合 $P_{m}$ 。 $P_{m}$ 包含2f+1个相同的准备消息。

当视图v+1的主节点收到2f个相同个视图更改消息，向其他副本广播新视图消息 $<new-view,v+1,V,O>$ ， $V$ 是2f+1个视图更改消息， $O$ 的计算规则如下： 1.确定序列号 $min_s$ 和 $max_s$ 。其中 $min_s$ 等于 $V$ 中稳定检查点序列号, $max_s$ 等于 $V$ 中最大prepare消息序列号。 2.主节点为 $min_s$ 和 $max_s$ 之间的每一个序列号n分配pre-prepare消息。如果 $V$ 中包含n对应的 $P$ 组合，则对应的预准备消息为 $<pre-prepare,v+1,n,d>$ （也就是说序列号n对应的请求有2f+1个prepare消息，在新视图中依然提交这个请求）。如果 $V$ 中不包含n对应的 $P$ 组合，则提交null消息为 $<pre-prepare,v+1,n,d<null> >$ ，即不做任何处理。