当前位置:   article > 正文

Fisco共识算法:PBFT_pbft的特点

pbft的特点

一、PBFT 与拜占庭问题

很多人喜欢玩狼人杀,我用狼人杀跟拜占庭将军问题做个类比。
在狼人杀开局的时候,你是好人,并且不知道自己的队友是谁,也不知道狼人是谁,但所有的好人都有一个共同的目的:干死狼人,好人获胜。所以游戏中需要使用技巧和策略,达成目的。
拜占庭将军问题是类似的,好的将军不知道其他将军是好的,还是坏的,但所有好的将军的目的是:行动一致,共同进退。所以,它们也需要策略达成一致。
BFT 是一类解决拜占庭将军问题的策略/算法:让非拜占庭节点达成一致的算法。在这类论文中,拜占庭节点指“坏”的将军,非拜占庭节点指“好”的将军。

PBFT 作为解决拜占庭问题的策略:非拜占庭节点不知道哪些是拜占庭节点,哪些是非拜占庭节点,PBFT 要让非拜占庭节点达成一致。PBFT算法天然适用于区块技术中,来解决共识问题。

PBFT拥有一个很大的一个特点:容错,可以在少数节点作恶场景中达成共识。它采用签名、签名验证、哈希等密码学算法确保消息传递过程中的防篡改性、防伪造性、不可抵赖性,但是PBFT只能有不少于 ( 2*f+1 ) 个非恶意节点正常工作,该系统就能达成一致性。

二、Fisco是怎么应用PBFT

1、关键概念

(1)节点ID && 节点索引
为了防止节点作恶,PBFT共识过程中每个共识节点均对其发送的消息进行签名,对收到的消息包进行验签名,因此每个节点均维护一份公私钥对,私钥用于对发送的消息进行签名,公钥作为节点ID,用于标识和验签。

  • 节点ID : 由于节点ID(公钥)就是一个很长的二进制字符串,在共识消息中包含该字段会耗费部分网络带宽,FISCO 引入了节点索引,在本地缓存一份每个节点的公钥以及对应每个节点的ID(例如:1、2、3…)的列表。发送网络消息包时,只需要带上节点索引,其他节点即可以从公共的共识节点列表中索引出节点的ID,进而对消息进行验签:
  • 节点索引 : 每个共识节点ID在这个列表中的位置。

(2)视图(view)
就是根据view和block_number来计算出在本轮共识的leader是谁。计算公式如下:

leader_idx = (view + block_number) % node_num
  • 1

可以说view值就是对应leader的索引。根据上面这个公式可以看出,当没有leader不是作恶节点,block正常上链,block_number是自增的,view值是不变的,那么leader是轮流做。当leader是作恶节点,发现leader是作恶节点时,就会全局广播view+1,这是block_number是没有发生变化的,导致切换leader,从新共识。

2、共识流程

(1)系统架构流程
在这里插入图片描述
PBFT共识主要包括两个线程:
PBFTSealer: PBFT打包线程,负责从交易池取交易,并将打包好的区块封装成PBFT Prepare包,交给PBFTEngine处理;
PBFTEngine: PBFT共识线程,从PBFTSealer或者P2P网络接收PBFT共识消息包,区块验证器(Blockverifier)负责开始执行区块,完成共识流程,将达成共识的区块写入区块链,区块上链后,从交易池中删除已经上链的交易。

(2)PBFT核心流程
在这里插入图片描述
下面对三个阶段详细展开叙述。

3、三阶段

PBFT共识算法中,共识节点轮流出块,每一轮共识仅有一个leader打包区块,leader索引通过公式(block_number + current_view) % consensus_node_num计算得出。
节点计算当前leader索引与自己索引相同后,就开始打包区块。区块打包主要由PBFTSealer线程完成Prepare包,交给PBFTEngine处理进行广播。
(1)pre-prepare阶段:
每个节点都会接收到由leader节点完成Prepare包,并对prepare包做一下校验:

  • Prepare包合法性判断
  • 缓存合法的Prepare包
  • 空块判断:若Prepare请求包含的区块中交易数目是0,则触发空块视图切换,将当前视图加一,并向所有其他节点广播视图切换请求
  • 执行区块并缓存区块执行结果: 若Prepare请求包含的区块中交易数目大于0,则调用BlockVerifier区块执行器执行区块,并缓存执行后的区块
  • 产生并广播签名包:基于执行后的区块哈希,产生并广播签名包,表明本节点已经完成区块执行和验证。

也就是说,假如包内有交易,会对每一笔交易进行验证,验证后会得出一个结果,这区块能不上链,把这个结果跟自己的签名信息广播给其他节点。
(2)Prepare阶段:
本阶段,已经开始收集其他节点给出结果,并作出判断,最终是否进行上链。会做出一下校验:

  • 签名包合法性判断:主要判断签名包的哈希与pre-prepare阶段缓存的执行后的区块哈希相同
  • 缓存合法的签名包:节点会缓存合法的签名包
  • 判断pre-prepare阶段缓存的区块对应的签名包缓存是否达到2*f+1,若收集满签名包,广播Commit包,进行广播Commit包之前,要做检验给出检验结果。
  • 若收集满签名包,备份pre-prepare阶段缓存的Prepare包落盘,为了防止Commit阶段区块未提交到数据库之前超过2*f+1个节点宕机

==注意: 只要接受到f+1节点给出结果一样,就能最终判定这个区块到底是否能够上链。我们试想,作恶节点有f个,当f+1个节点给出结果时,必然有一个结果一定是正确的。 ==

(3)Commit阶段:jiu
共识节点收到Commit包后,进入Commit阶段,jiu此阶段工作流程包括:

  • Commit包合法性判断:主要判断Commit包的哈希与pre-prepare阶段缓存的执行后的区块哈希相同
  • 缓存合法的Commit包
  • 判断pre-prepare阶段缓存的区块对应的Commit包缓存是否达到2*f+1,若收集满Commit包,则将新区块落盘

此过程和Prepare阶段差不多,是为了保持全局数据一致性。

三、为什么三个阶段才能达到共识?

Prepare阶段 是一个局部一致,不是全局诚实节点的一致,即节点 i 看到了非拜占庭节点认可了 ,但整个系统包含 3f+1 个节点,异步的系统中,存在丢包、延时、拜占庭节点故意向部分节点发送 Prepare 等拜占庭行文,节点i 无法确定,其他节点也达到 Prepare节点状态做出结果。如果少于 f 个节点完成 Prepare,然后执行了上链,系统就出现了不一致。所以,前 2 个阶段的消息,并不能让非拜占庭节点完全达成一致。

四、PBFT消息转发优化

在这里插入图片描述

  • node0向{node1, node2, node3}发送PBFT消息,发现{node1, node3}不在连接列表内,则将PBFT消息msg的forwardNodes字段设置为{node1, node3},并将其转发给node2;
  • node2收到node1的PBFT消息后,判断forwardNodes字段不为空,则遍历邻居节点列表{node1, node3},并将邻居节点从forwardNodes中移除;
  • node2向node1和node3转发更新后的PBFT消息msg;
  • node1和node3收到msg后,判断forwardNodes字段为空,认为该消息已经到达了所有节点,不继续转发PBFT消息。
声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/繁依Fanyi0/article/detail/600090
推荐阅读
相关标签
  

闽ICP备14008679号