区块链4：共识机制——深入讲解PBFT算法

@目录

背景介绍

共识机制是区块链的一个重要知识领域。 它的作用是保持分布式节点之间的一致性，从而支持去中心化。 在区块链之前，有各种分布式共识机制。 区块链是发明出来的，但区块链对共识机制的推广和进步有着重要的影响。

共识算法分类

根据应用场景，共识算法可以分为两类，1.有坏人节点，2.没有坏人节点。

1. 存在恶意节点，典型的拜占庭问题，即系统中可能存在节点故意传输虚假结果，造成分布式系统结果错误。 这种情况的重点是达成共识，即在有不良行为者在场的情况下，每个人都认可这一结果。 其中BFT、PBFT、POW、POS都属于这一类。

2.没有坏人。 这种分布式共识算法只需要保证所有节点的行为一致，在部分节点宕机后还能继续工作。 一般用于封闭的分布式系统，包括Raft和Paxos。

对于几种常见的共识算法，大部分都有类似的思路，即一个组长（primary）带领N个成员（backup）工作，组长发送工作收集每个节点的状态，然后判断是否是结果是一致的，类似于分布式事务的两阶段提交。

其中比特币的共识算法是，不同的算法主要以不同的思路解决这些问题。

系统如何判断共识？ 当组长宕机或部分节点宕机时，如何保持系统可用性？ 出现分叉时如何处理两边的结果？ 拜占庭容错

这部分讲解PBFT算法以及如何解决上述问题。

PBFT的算法思想是由状态机来操作的，包括节点状态和消息状态。 组长带领大家统一处理消息，消息是否继续迁移到下一个状态取决于有多少节点达成一致，最终消息到达处理端。 状态。

消息处理：

消息状态迁移路径：request -> pre-prepare -> prepare -> commit -> reply

C代表Client，客户端向系统主节点（0：组长）发送请求，请求开始进入处理阶段

pre-prepare ：主节点参与为request分配一个唯一编号request-number n，并将request和n一起广播，形成pre-prepare消息给所有成员（备份节点）

prepare ：所有成员（备份节点）收到pre-prepare报文，依靠签名字段检查报文是否来自主节点，确认无误后，将请求号和成员签名组成prepare报文节点，并向所有其他成员广播以表示他们认可此请求已编号并准备就绪。

Commit：所有节点，如果收到prepare消息，依靠签名来检查是否正确。 如果prepare消息的数量超过节点总数的三分之二，则认为系统已达成共识，批准请求和请求数，并向所有节点广播commit消息，表明该节点可以执行请求业务。

Reply：所有节点，如果收到commit消息，依靠签名来检查消息是否正确。 如果提交消息的数量超过所有节点的三分之一，它们将完成请求所需的业务，构造回复消息，并直接回复给客户端。 客户端根据是否收到三分之一以上节点的正确回复来判断系统是否完成请求。

上图和描述是PBFT的请求处理流程，那么回到上面的问题，

问题一：系统是否达成共识？

这里有两个阶段，准备和提交。 如果全网超过三分之二的prepare就达成共识，如果commit超过三分之一就达成共识。

简单来说，坏点应该在三分之一以下。

灵魂拷问

1、为什么不到三分之一，而不是二分之一？

如果多数服从多数，二分之一确实可以满足，但是这里有两个阶段：prepare和commit。

n个节点，设置错误节点f，first到f为错误节点，f+1到n为好节点pre-prepare-prepare，nf个节点都正确广播prepare消息，prepare-commit，当收到nf确认时节点收到一条消息，无法确认这里的nf条消息有多少f个节点，最多可能有f个节点比特币的共识算法是，即这nf条消息中至多有f条是假消息，不会影响共识结果, 所以 nff > f 所以 f < n/3。

另一种理解是，nf个正常节点之间，如果有分歧，也可以达成共识，那么

(nf)/2 >f, 得到 n>3f, f

从上面的描述也可知，对于request r1，commit(m)如果成功达成一致，就不可能达成commit(m')，所以不可能有分叉。 第三个问题也在这里得到解答（问题3，有分叉时两边结果如何处理，分叉不存在）。

跟进

为什么要把两个阶段分开，一个阶段搞定不是很好吗？

——这是为了保证请求的顺序。 第一阶段分配序号，第二阶段完成业务。

这里还提到，在commit阶段，k个节点可能会进行视图转换。 这是什么？

——这就涉及到第二个问题，下面会进行说明。

问题二：当团长宕机或部分节点宕机时，如何保持系统可用性？

视图转换

以上保证了分布式系统的正确性和安全性，做正确的事，而视图转换是为了可用性的活跃性。 如果主节点宕机，系统会发生什么情况？ 要确保系统继续可用，请使用 view-change。

PBFT有一个全局视图编号视图编号：v，主节点primary根据v mod n =i得到节点i作为主节点。 视图转换意味着v增加，主节点也相应地转移到另一个节点。

当client向primary发送请求，在一定时间内没有收到回复，就会向其他backup节点发送请求。 备份节点收到请求后，启动一个定时器。 如果定时器超时，请求还未执行（commit尚未达成共识），则backup节点发起view-change

Backup节点会广播view-change消息，包括原view号v和下一个view号v+1

如果节点收到超过三分之二的视图更改消息，则表示视图更改已达成共识。

当 v+1 mod n = j 时，新的主节点 j 在收到足够多的视图更改消息后，广播新视图消息告诉其他节点使用新视图。

其他节点收到new-view后，确认消息签名正确，进入新视图；

有了视图转换，如果主节点挂了，会触发视图转换来替换另一个主节点。 如果下一个主节点也宕机，则继续切换，直到找到可用的主节点。 因此，保证只有三分之二以上的节点是好的，系统是可用的。

Usability liveness，还要保证view 1转换的时候，有的节点可能已经提交了sequence n，而有的节点只commit了sequence n-1。 视图传输后，如何保证请求在所有节点上都能正确、一致地执行。

这也引出了下一个问题，检查点机制。

检查点机制：

这里需要检查点，这里的检查点和其他系统日志检查点基本一样。 系统定时创建检查点，记录最新稳定提交的操作，广播检查点消息。 当节点收到超过三分之二的已创建检查点消息时，检查点达成共识。 视图转换的时候带上最新的checkpoint，checkpoint之后的request被认为是不稳定的，需要重做。

总结

PBFT算法通过节点消息状态机实现请求处理的一致性，再通过视图转换，检查点机制保证系统的可用性。 本文简单介绍了这几个方面的原理，同时也过滤了具体的算法细节。 有兴趣的可以看看论文[引用1]

1篇PBFT算法论文

历史

区块链3：深入剖析比特币交易原理

区块链二：比特币的区块数据结构

区块链一：区块链应用介绍与展望