关于PBFT的备忘

关于PBFT的备忘

论文地址：http://pmg.csail.mit.edu/papers/osdi99.pdf

1、为什么节点数至少是3f+1

在很多关于BFT的共识算法中，都说在拜占庭节点为 f 个的时候，要保证整体的节点数至少要3f+1。在论文中是这么描述的：当有f个节点是故障的时候，至少要有3f+1个节点来保障系统的安全性和活性。需要3f+1个节点是因为在系统中可能存在f个故障节点，而收到的消息中，有f个消息可能是错误的，因此需要收到的消息中有至少f+1个是正确的。因此整个系统至少要保证3f+1个节点。

这里将故障节点和拜占庭节点做了区分，诚实节点不回消息即为故障，拜占庭节点会回消息但可能全部是假消息。

2、正常共识流程

前提：所有节点的状态机初始状态是一致的

pre-prepare阶段

primary：收到client的requst,发送<<pre-prepare,v,n,d>,m>给其他节点，其中v代表当前轮次，n是共识的序列号，d是消息m的hash, m是消息。

replica：

​ 1、验证request

• hash校验，签名校验

• 当前轮次是v

• 没有接受过相同<v,n>的pre-prepare 消息

• n是合法的（为了防止拜占庭节点用超大的序列号）

  2、对pre-prepare消息投票并广播<prepare,v,n,d,i>，进入prepare阶段。其中i表示是第i个replica

prepare阶段

​ replica（包含primary）：

​ 1、收集prepare消息，至少f+1个非拜占庭节点的消息，实际应收到不少于2f（primary不发送prepare消息，如果发送的话就是2f+1）个消息。

​ 2、commit, 广播<COMMIT,v,n,D(m),i>

commit阶段

​ replica：收集commit消息，至少f+1个非拜占庭节点的消息，实际应收到不少于2f+1个消息，将结果返回给client

3、为什么是2次投票

PBFT的2阶段投票分别为pre-prepare->prepare,prepare->commit 2个阶段。(3阶段协议，2次投票)

其中pre-prepare -> prepare节点用来确定同一个view下各个节点的request的顺序是一致的

prepare->commit阶段用于确定各个节点commit的顺序是一致的。

假设0轮投票：

​ replica收到request就进行提交，无法确定自己收到的跟其他节点收到的是一致的，会很容易导致分叉。如主节点是拜占庭节点，发送不同的request给不同的节点。

假设1轮投票：

​ replica进行一轮投票后进行提交，此时虽然节点收到了足够的投票来证明其他节点收到的request是一致的，但无法确定其他节点是否收到了足够数量的投票。因此只有1轮投票会出现自己提交而其他节点没有提交的情况。

备忘：
hotstuff需要3轮投票也是一样的原因，需要多一轮投票是因为hotstuff的网络模型是投票发给leader，而不是广播。
因此可以认为replica在收到第一轮投票结果的时候确认了 各个节点request顺序是一致的，在收到第二轮投票结果的时候确认了 各个节点都收到了第一轮投票（即各个节点都知道其他节点request顺序与自己一致），在收到第三轮投票结果的时候可以确认多数节点都会提交相同的request，因此提交request。
如果缺失了一轮投票，2次投票后就提交request。那replica就无法确定其他的replica是否会提交相同的区块，因为投票结果是leader发送的，有可能leader只将第二次投票结果发给了一部分replica，而另一部分replica因为一些原因（网络原因或者leader造假）导致没有收到第二次投票结果所以不会提交request。