当前位置:   article > 正文

PBFT算法_持续更新_pbft节点更新

pbft节点更新

 

1、PBFT解决问题

BFT是区块链共识算法中,需要解决的一个核心问题。

以比特币和以太访为代表的POW,EOS为代表的DPOS,以及今后以太访逐渐替换的共识算法POS,这些都是公链算法,解决的是共识节点众多情况下的BFT;而PBFT是在联盟链共识节点较少的情况下BFT的一种解决方案。

 

PBFT算法由于每个副本节点都需要和其他节点进行P2P的共识同步因此随着节点的增多,性能会下降的很快,但是在较少节点的情况下可以有不错的性能,并且分叉的几率很低。PBFT主要用于联盟链,但是如果能够结合类似DPOS这样的节点代表选举规则的话也可以应用于公链,并且可以在一个不可信的网络里解决拜占庭容错问题,TPS应该是远大于POW的



作者:ether029
链接:https://www.jianshu.com/p/78e2b3d3af62
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。



作者:ether029
链接:https://www.jianshu.com/p/78e2b3d3af62
来源:简书
 

2、过程


首先了解一下几个基本概念:(从区块链的视角)

  • replica:即区块链节点,提供“副本复制”服务
  • client:向primary发起请求的客户端节点,在区块链中往往跟primary合二为一
  • primary:区块发起者,在收到请求后生成新区块并广播
  • backup:区块验证者,在收到区块后进行验证,然后广播验证结果进行共识
  • view:一个primary和多个backup形成一个view,在该view上对某个区块进行共识
  • sequence number(n):由primary指定的一个数字,可以理解为区块高度
  • checkpoint:如果某个sequence number对应的区块收到了超过2/3的确认,则称为一个checkpoint

另外,primary是所有节点轮流做的,每个view上都会选出一个新的primary。
 

三阶段协议是PBFT的核心,参见下图:

è¿éåå¾çæè¿°

从发起请求到最终收到reply,中间的共识过程需要经过3个阶段:

  1. pre-prepare:primary(主节点)收到请求,生成新区块并广播;
  2. prepare:所有replica(副节点)收到区块后,广播区块验证结果,同时等待接收超过2/3的节点的广播;
  3. commit:收到2/3的节点广播或者超时后,再次发送广播,同时再次等待接收超过2/3的节点的广播;

大致逻辑

第一次等待超过2/3的节点广播,是为了确认“已经有超过2/3的节点收到区块了”。但是这只是你自己知道,别人并不知道啊,因此需要再发送一次广播,告诉别的节点“我已经确认有超过2/3的节点收到区块啦”;而第二次等待超过2/3的节点广播,则是为了确认“已经有超过2/3的节点确认(有超过2/3的节点收到区块啦)”,此时说明已经达成共识,可以把该区块写到链上了。
 

详细步骤

https://blog.csdn.net/kojhliang/article/details/71515199

里面有高低水位、checkpoint的解释

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/Gausst松鼠会/article/detail/600086
推荐阅读
相关标签
  

闽ICP备14008679号