Hyperledger Fabric的PBFT源码分析（一）

最新推荐文章于 2026-04-02 22:41:47 发布

原创

最新推荐文章于 2026-04-02 22:41:47 发布 · 1w 阅读

本文介绍了PBFT（Practical Byzantine Fault Tolerance）共识算法的基本原理，包括算法公式、PBFT执行过程和弱证书概念。内容涵盖客户端请求流程、主节点分配编号、准备和提交阶段，以及在Hyperledger Fabric中的代码目录结构。

一、PBFT的原理概述

1.算法公式:

replicaCount int 变量定义在pbftCore结构体中
N (N在代码中对应replicaCount整型变量)是所有replicas的集合，每一个replica用一个整数来表示，如{ 0, 1, 2, 3,...N - 1 }

N-1 = 3f -----> f = N- 1/3

f 是最大可容忍的出错节点，也就是说准许错为1/3

2.图解PBFT执行过程

客户端发过来的请求其实是发给主replica，这里假设所得还没有选出主replica

这里大家估计也可以看出来图3和图4是一样的，其实这是一个互相确认的过程

客户端

Client---->REQUEST--->replicas
1. REQUEST携带 operation, timestamp，给每一个REQUEST加上时间戳，这样后来的REQUEST会有高于前面的时间戳

2.replicas会接收请求，如果他们验证了条请求，就会将它写入到自己的log中。在共识算法保证下每个replica完成对该请求的执行后直接将回复返回给client：

3.REPLY携带当前的view序号和时间戳，还有replica节点的编号，会返回执行结果

4.共识算法中有一个weak certificate，在这里，client也会等待weak certificate：即有f+1个replicas回复，并且它们的回复拥有相同的 t 和 r，由于至多有f个faulty replicas，所以确保了回复是合法的。我们叫这个weak certificate为 reply certificate。

5.处于active状态每一个replica会与每一个的client共享一份秘钥。

pre-prepare阶段

1.主节点收到来自Client的一条请求并分配了一个编号给这个请求，
2.主节点会广播一条PRE-PREPARE信息给备份节点，
3.这个PRE-PREPARE信息包含该请求的编号、所在的view和自身的一个digest。
4.直到该信息送达到每一个备份节点，接下来就看收到信息的备份节点们同不同意
5.主节点分配给该请求的这个编号n，即是否accept这条PRE-PREPARE信息，

6.如果一个备份节点accept了这条PRE-PREPARE，它就会进入下面的prepare阶段。

prepare阶段

1.备份节点进入prepared阶段后，广播一条PREPARE信息给主节点和其它的备份节点，直到PREPARE信息都抵达那三个节点。同时，该备份节点也会分别收到来自其它备份节点的PREPARE信息。
2.该备份节点将综合这些PREPARE信息做出自己对编号n的最终裁决。当这个备份节点开始综合比较来自其它两个备份节点的PREPARE信息和自身的PREPARE信息时，如果该备份节点发现其它两个节点都同意主节点分配的编号，又看了一下自己，自己也同意主节点的分配，a quorum certificate with the PRE-PREPARE and 2 f matching PREPARE messages for sequence number n, view v, and request m，如果一个replica达到了英文所说的条件，比如就是上面的斜体字描述的一种情况，那么我们就说该请求在这个replica上的状态是prepared，该replica就拥有了一个证书叫prepared certificate。那我们是不是就可以说至此排序工作已经完成，全网节点都达成了一个一致的请求序列呢，每一个replica开始照着这个序列执行吧。这是有漏洞的，设想一下，在t1时刻只有replica 1把请求m（编号为n）带到了prepared状态，其他两个备份节点replica 2， replica 3还没有来得及收集完来自其它节点的PREPARE信息进行判断，那么这时发生了view change进入到了一个新的view中，replica 1还认为给m分配的编号n已经得到了一个quorum同意，可以继续納入序列中，或者可以执行了，但对于replica 2来说，它来到了新的view中，它失去了对请求m的判断，甚至在上个view中它还有收集全其他节点发出的PREPARE信息，所以对于replica 2来说，给请求m分配的编号n将不作数，同理replica 3也是。那么replica 1一个人认为作数不足以让全网都认同，所以再新的view中，请求m的编号n将作废，需要重新发起提案。所以就有了下面的commit阶段。
需要注意的是，该备份节点会将自己收到的PRE-PREPARE和发送的PREPARE信息记录到自己的log中。
该备份节点发出PREPARE信息表示该节点同意主节点在view v中将编号n分配给请求m，不发即表示不同意。
如果一个replica对请求m发出了PRE-PREPARE和PREPARE信息，那么我们就说该请求m在这个replica节点上处于pre-prepared状态。

Commit阶段

紧接着prepare阶段，当一个replica节点发现有一个quorum同意编号分配时，它就会广播一条COMMIT信息给其它所有节点告诉他们它有一个prepared certificate了。与此同时它也会陆续收到来自其它节点的COMMIT信息，如果它收到了2f+1条COMMIT（包括自身的一条，这些来自不同节点的COMMIT携带相同的编号n和view v），我们就说该节点拥有了一个叫committed certificate的证书，请求在这个节点上达到了committed状态。此时只通过这一个节点，我们就能断定该请求已经在一个quorum中到达了prepared状态，寄一个quorum的节点们都同意了编号n的分配。当请求m到达commited状态后，该请求就会被该节点执行。

由此观之核心代码执行的过程如下

二、共识算法代码解析

1.代码目录结构

// GetEngine returns initialized peer.Engine

//============================================================================

//它初始化一个consenter和一个helper，并互相把一个句柄赋值给了对方。

//这样做的目的，就是为了可以让外部调用内部，内部可以调用外部

//============================================================================

func GetEngine(coord peer.MessageHandlerCoordinator) (peer.Engine, error) {

    var err error

    engineOnce.Do(func() {

        engine = new(EngineImpl)

        engine.helper = NewHelper(coord)

        engine.consenter = controller.NewConsenter(engine.helper)

        engine.helper.setConsenter(engine.consenter)

        engine.peerEndpoint, err = coord.GetPeerEndpoint()

        engine.consensusFan = util.NewMessageFan()

        go func() {

            logger.Debug("Starting up message thread for consenter")

            // The channel never closes, so this should never break

            for msg := range engine.consensusFan.GetOutChannel() {

                engine.consenter.RecvMsg(msg.Msg, msg.Sender)

}()

})

    return engine, err

//==============================================================================

// NewConsenter constructs a Consenter object if not already present

//==============================================================================

//==============================================================================

//调用controller获取一个plugin，当选择是pbft算法时，它会调用pbft.go 里的

//GetPlugin(c consensus.Stack)方法，在pbft.go里面把所有的外部参数读进算法内部

//==============================================================================

func NewConsenter(stack consensus.Stack) consensus.Consenter {

    plugin := strings.ToLower(viper.GetString("peer.validator.consensus.plugin"))

    if plugin == "pbft" {

        logger.Infof("Creating consensus plugin %s", plugin)

        return pbft.GetPlugin(stack)

    logger.Info("Creating default consensus plugin (noops)")

    return noops.GetNoops(stack)

controller目录下是共识插件选择模块的函数
---->HyperLedger提供了两种算法PBFT和noops
---->默认单节点情况下使用noops即相当于没有共识算法

func NewConsenter(stack consensus.Stack) consensus.Consenter {

    plugin := strings.ToLower(viper.GetString("peer.validator.consensus.plugin"))

    if plugin ==

最低0.47元/天解锁文章