什么是 pBFT？: P! H( \5 A' H8 }
Practical Byzantine Fault Tolerance ，实用拜占庭容错。
. A  k/ ]; w: Z7 y; k  O什么是 BFT？
/ m# K2 e; \# I: Z$ s: D4 c8 u$ PByzantine Fault Tolerance ，拜占庭将军问题。
2 x. t6 x8 }( \2 P4 x! m  m3 G拜占庭将军的问题是什么？7 B' D1 W, B5 J; }* N0 D- R6 N" ]
简单地说，是一种少数服从多数的问题。拜占庭罗马帝国的每块封地都驻扎一支由将军统领的军队，将军与将军之间只能靠信差传递消息。在战争时期，拜占庭军队只有占据人数优势情况下，才能夺取目标的胜利。但在军队内有可能存有叛徒，当敌军与之联合起来大于忠诚将军数量时，进攻就会失败。' Q$ b, o! U8 o- j, R( _
pBFT 算法的提出主要是为了解决拜占庭将军问题。$ b2 P' R$ ~9 y; o/ [4 S6 B
要解决这个问题的前提是通信必须是可靠的，如果通信不可靠则问题无解。而拜占庭将军问题中通过通信不可靠而试图达成一致的结果几乎不可能或者非常困难。所以要在通信可靠的前提下来解决此问题。也就是在系统上有一些恶意组件不断发送错误信息的情况下让系统依旧正常运行的能力。
7 `) Z: `8 d# }7 H+ r8 R# |pBFT 原理& H: v+ p; C+ z- l8 F# V
在系统中有一个节点会被当做主节点，而其他节点都是子节点。系统内的所有节点都会相互通信，最终目标是大家能以少数服从多数的原则达成数据的共识。
. G- u* L% ^1 n2 x0 ^! D7 L- h6 r达成共识的过程7 V! }5 _- O0 s$ e
第一步，客户端发一个请求给主节点去执行某个操作；
. g; ?1 `9 Y7 \, I" q3 O第二步，主节点通信给各个子节点；
, s6 {) P+ D" s" s& V: i. e第三步，所有节点通过算法并把结果返回给客户端；
5 A/ c4 K. r4 |, |7 Q% d' W第四步，当客户端「收到结果」后，过程结束；& R9 q9 M( C4 x% V- s9 t
第四步中收到结果时的最大容错节点数$ a% g1 {# v: y& C0 f0 ]: s
假设 n 是总节点数，f 为有问题的节点，问题包括两种，一种是故障节点 f，一种是作恶节点 f。故障节点收到通信后不会返回结果，作恶节点收到通信后会返回错误的结果。在统计返回节点数时，有问题的节点 f 会被排除在外，所以只要正确通信数大于作恶节点数 f 即可保证本次通信正常，即 f + 1 个正确节点，也就是说总节点数n 包括 f + 1 个正确节点，f 个作恶节点和 f 个故障节点，即 3f + 1 = n，因此pBFT算法支持的最大容错节点数是 f = （n-1）/3，也就是超过 1/3 的节点数即可。2 V3 B% v3 k; f' g9 m/ q

1 G2 v& F* A1 e9 p! ^第三步中的pBFT算法
+ R( P3 f6 t4 A3 L% y! z- n: C其中! N4 k0 _& C+ I3 c& w
C代表客户端，0，1，2，3 代表节点的编号，# g2 O4 _# [& ^, r8 X) f# g; P! N
打叉的3代表故障节点或者是问题节点，这里表现为故障节点。2 z0 {. ?+ S$ K* x8 Z, z
0 是主节点。: b, a" I9 t- o$ S
算法的核心三个阶段分别是
0 I) Q% _7 W! v8 A7 _! dpre-prepare预准备，由于主节点不会发布两条内容不同的通信，则如果收到节点编号相同而内容不同的通信，子节点会选择拒绝请求。
# T. F' ^5 I& D  r# Q* Hprepare 准备，由于同时有n个节点接受请求进行通信，所以在一定时间范围内，如果收到超过 2f 个不同节点的 prepare 消息，就代表 prepare 阶段已经完成。* {+ W! W5 ~- B4 ?. v5 }$ Y5 {& y
commit提交，和prepare同理，当收到 2f+1 个 commit 消息后（包括自己），代表大多数节点已经进入 commit 阶段，这一阶段已经达成共识，于是节点就会执行请求，写入数据。2 t% w# d2 U* f
有关其他技术
3 g9 C& b4 B8 R; Pcheckpoint 、stable checkpoint和高低水位
# X0 b, a- ^% i( T7 z4 U$ Lcheckpoint，是当前节点处理的最新请求序号。比如一个节点正在共识的一个请求编号是1，那么对于这个节点，它的 checkpoint 就是1。
- i: [* i; ~3 Z2 Z8 y, Y  D7 dstable checkpoint，是已经共识完成的最大请求序号。也就是 f + 1个节点请求编号是10 ，那么stable checkpoint就是10。
' W( p9 w) N6 Y; K9 E' x7 c8 \6 W6 l6 fstable checkpoint为的是减少内存占用。当稳定是stable checkpoint是10 ，那么代表 10 号之前的记录已经共识过的了，可以删掉了。% C+ b; B  s7 E/ u+ C2 F8 P; n
stable checkpoint 可以设置一个范围，即水位，他的最小值叫下水位，最大值就高水位，他们的差 L 可以自定义。为了减少各个节点之间最大请求序号的差。假设水位是 50 ~ 100，当 a 节点到达100后，会等待 b 节点到达接近 100 时，自动更新水位范围，比如变成 100 ~ 150。这样节点就可以基本同步重新进行操作了。; ]5 l' t- B6 L8 k& {8 |3 y
更换主节点, {0 b; `  u( v; J( J8 y
当主节点出现故障，就会触发 ViewChange + 1 事件viewchange 会有三个阶段，分别是
1 F# [+ c4 ]; j- pview-change ， 从节点认为主节点有问题时，会向其它节点发送 view-change 消息，当前存活的节点编号最小的节点将成为新的主节点。4 C+ q2 D8 |* R8 m' b9 P) Z: e
view-change-ack ，新的主节点收到 2f 个 view-change 消息，则证明 view-change有效，并广播new-view 消息。
, s4 B5 k- `6 O2 Znew-view ，新主节点会继续执行上个视图未处理完的请求，其它节点验证 new-view 消息通过后，就会处理执行pbft 过程并进入ViewChange + 1。
; L# f& l/ v* V" `& P$ O4 fpBFT 的优点3 Y' a2 W9 T, |; y, `
高效，由于各个节点达成共识是在同一时刻决定的首先，所以pBFT 无需等待确认。! \0 O6 v( x  y! K& T: Z9 }! a. }
节能，因为 pBFT 是无需挖矿的，所以pBFT 不用耗能。/ M0 e2 p' V3 d
pBFT 的缺点7 p5 I1 ]# I4 c) \, c( U7 G9 P5 L
中心化，由于要保证各个节点间的频繁的通信，所以节点数不能太多。
2 h& \1 M4 _. ]/ d门槛高，由于pBFT 不能防止女巫攻击，也就无法防御一个恶意用户用多个账户来进行共识的造假行为，所以需要审核加入节点。
6 t4 Y. M" R% J所以 pBFT 比较适合需审批的联盟链，不太适合做无条件加入的公链。