草庐IT

PBFT共识算法的个人见解

胡桃木子 2024-02-10 原文

前置知识

CFT与BFT的区别

  • CFT:节点出现故障( crash 或 fail-stop),即不响应但不会伪造信息的情况称为“非拜占庭错误”( non-byzantine fault)或“故障错误”( Crash
    Fault),处理非拜占庭错误的算法有:paxos、raft和其变种;
  • BFT:节点伪造信息恶意响应的情况称为“拜占庭错误”( Byzantine Fault),对应节点为拜占庭节点。处理拜占庭错误算法有:pbfthotstuff算法;

同步、异步、部分同步概念

  • 异步(asynchrony):系统中各个节点可能存在较大的时钟误差、消息传递时间是任意长的,各节点对 消息的处理时间也可能是任意长的。
  • 同步(synchrony):系统中各个节点的时钟误差存在上限、消息传递在一定时间内完成,各节点完成处 理消息的时间是一定的。
  • 部分同步(partial synchrony):在一个全局稳定时间(GST)之前,系统可能处于异步状态,GST之后,会有一段同步的状态。

与公有链共识算法的区别

公有区块链不可能同时共识区块1和区块2,但在pbft中,交易1和交易2的共识是并行的。

  • 在公有区块链中,每一个区块串行进行共识,共识的对象是区块,区块包含一段时间收集的交易

  • 在pbft中,共识的对象是每一个交易(可以说在pbft中没有区块这个概念),交易共识的过程是并行(限定在高低水位,后续解释)

关于N>=3f+1

假设总共有N个节点,其中有F个拜占庭节点,拜占庭节点是可以不发送消息的,所以为了保证活性,主节点收到N-F个节点发送来的消息就要做出判断,考虑极端情况:N-F个消息中恰好有F个是拜占庭节点发来的,因为网络存在延迟等原因,诚实节点的消息可能会比拜占庭节点的消息更晚到达。此时N-F个消息中只有N-2F个是正确节点发送来的,所以为了保证消息的正确性,即需要诚实节点数量大于拜占庭节点F,则有N-2F>F,则至少需要保证N=3F+1。

具体流程


关于整个流程的具体流程讲解可以参考:简书,本文针对论文中的重点和难点进行提取。

重点提取

  • pre-prepare阶段和prepare阶段确保所有正常节点对同一个视图中的请求排序达成一致,prepare和commit两个阶段用来确保在不同的视图之间的请求也是严格排序的。

证明1: 当节点收到了一个pre-prepare和对应的2f个prepare消息之后,进入准备完毕阶段,记作prepared(m, v, n, i).。假如有prepared(m,v,n,i)为真且prepared(m’,v,n,j)也为真,那么可以由接受prepared的条件可以看出,有f+1个好节点(包括他本身)发出了prepare消息接受m,另有f+1个好节点发出了prepare接受m’,这样好节点为2f+2
但是N=3f+1,好节点只有N-f=2f+1个,有矛盾。

证明2:**某个好节点i达到committed-local说明其至少接收了2f+1个节点的commit消息,所以至少有f+1个好节点的commit消息。好节点发送commit需要保证是已经进入prepared状态才行。这样就至少有f+1个好节点进入了prepared状态。如果发生视图转换的时候,新的主节点需要收到2f个来自其他不同节点的view-change消息(加上自己就是2f+1个消息)。网络中总有3f+1个节点,所以f+1个好节点肯定至少有一个会把已经prepared的消息发送到下一个视图中继续达成共识。

  • 视图轮换


  • pbft为什么需要三个阶段

如果一个节点达到了prepared状态,就认为全网共识了是有问题的,因为你收到凭证不代表其他人也受到足够的确认也生成凭证。想象一下,如果就你生成凭证的情况下,你认为全网已经共识了,甚至返回用户结果。这时发生viewchange,所有的交易都要被重放,新的View从2f+1个回复中重新生成pre-prepare,但是如果2f+1个回复中不包含你的消息,那么你认为全网已经共识的交易就会凭空消失,而此时你甚至已经返回用户结果了,这是很有问题的。所以需要加多一个commit阶段,commit阶段是让你知道别人也拿到这样的凭证的(因为一个节点达到了commited-local证明有f+1个好节点已经prepared),这样即使发生viewchange,因为Quorum的性质,保证你这个已经prepared凭证的消息,一定会出现再重放名单中。
这也暗示了,Viewchange会发生请求丢失的情况,因为收集的2f+1个回复中只能保证那个commit阶段完成的prepare凭证消息能够重放。那些没完成commit阶段的prepare凭证消息可能会丢失,没拿到prepare凭证的消息绝对会被丢失。这时就是可用性的问题了,用户长时间没收到结果会重新发消息(因为消息丢失了,只能这样)。同时,因为丢失问题,我们意识到中间有些序号是没有相应的消息的,此时新主会填充为null消息。

优缺点总结

优势

  • 首个实用的BFT容错算法,使得复杂度从指数级降到多项式级 O(n2);
  • 响应性(Responsiveness):在网络状况OK,主节点不犯错,拜占庭节点数量不超过f个时, 在下一个视图一定是可以达成共识的;

不足

  • 通信复杂度 O(n2) ,可扩展性低;
  • 视图转换的复杂度 O(n3),要是连续视图转换复杂度 O(f* n3),视图转换复杂,很“重”;
  • 视图转换期间只能接收viewchange、newview消息不能对外提供服务;
  • Safety和Liveness耦合,都需要通过视图转换来保障;
  • 去重机制没有提;

参考资料:

https://www.jianshu.com/p/0bef4fb1662b
https://blog.csdn.net/jason_cuijiahui/article/details/79613633
https://blog.csdn.net/u011537073/article/details/53519074
源码:https://github.com/Liukemeng/Fabric0.6-PBFT-Learning
原文:https://pmg.csail.mit.edu/papers/osdi99.pdf

有关PBFT共识算法的个人见解的更多相关文章

  1. 区块链之加解密算法&数字证书 - 2

    目录一.加解密算法数字签名对称加密DES(DataEncryptionStandard)3DES(TripleDES)AES(AdvancedEncryptionStandard)RSA加密法DSA(DigitalSignatureAlgorithm)ECC(EllipticCurvesCryptography)非对称加密签名与加密过程非对称加密的应用对称加密与非对称加密的结合二.数字证书图解一.加解密算法加密简单而言就是通过一种算法将明文信息转换成密文信息,信息的的接收方能够通过密钥对密文信息进行解密获得明文信息的过程。根据加解密的密钥是否相同,算法可以分为对称加密、非对称加密、对称加密和非

  2. 100个python算法超详细讲解:画直线 - 2

    1.问题描述使用Python的turtle(海龟绘图)模块提供的函数绘制直线。2.问题分析一幅复杂的图形通常都可以由点、直线、三角形、矩形、平行四边形、圆、椭圆和圆弧等基本图形组成。其中的三角形、矩形、平行四边形又可以由直线组成,而直线又是由两个点确定的。我们使用Python的turtle模块所提供的函数来绘制直线。在使用之前我们先介绍一下turtle模块的相关知识点。turtle模块提供面向对象和面向过程两种形式的海龟绘图基本组件。面向对象的接口类如下:1)TurtleScreen类:定义图形窗口作为绘图海龟的运动场。它的构造器需要一个tkinter.Canvas或ScrolledCanva

  3. ruby - 在 Ruby 中实现 Luhn 算法 - 2

    我一直在尝试用Ruby实现Luhn算法。我一直在执行以下步骤:该公式根据其包含的校验位验证数字,该校验位通常附加到部分帐号以生成完整帐号。此帐号必须通过以下测试:从最右边的校验位开始向左移动,每第二个数字的值加倍。将乘积的数字(例如,10=1+0=1、14=1+4=5)与原始数字的未加倍数字相加。如果总模10等于0(如果总和以零结尾),则根据Luhn公式该数字有效;否则无效。http://en.wikipedia.org/wiki/Luhn_algorithm这是我想出的:defvalidCreditCard(cardNumber)sum=0nums=cardNumber.to_s.s

  4. Ruby 斐波那契算法 - 2

    下面是我写的一个计算斐波那契数列中的值的方法:deffib(n)ifn==0return0endifn==1return1endifn>=2returnfib(n-1)+(fib(n-2))endend它工作到n=14,但在那之后我收到一条消息说程序响应时间太长(我正在使用repl.it)。有人知道为什么会这样吗? 最佳答案 Naivefibonacci进行了大量的重复计算-在fib(14)fib(4)中计算了很多次。您可以将内存添加到您的算法中以使其更快:deffib(n,memo={})ifn==0||n==1returnnen

  5. ruby-on-rails - Rails add_index 算法 : :concurrently still causes database lock up during migration - 2

    为了防止在迁移到生产站点期间出现数据库事务错误,我们遵循了https://github.com/LendingHome/zero_downtime_migrations中列出的建议。(具体由https://robots.thoughtbot.com/how-to-create-postgres-indexes-concurrently-in概述),但在特别大的表上创建索引期间,即使是索引创建的“并发”方法也会锁定表并导致该表上的任何ActiveRecord创建或更新导致各自的事务失败有PG::InFailedSqlTransaction异常。下面是我们运行Rails4.2(使用Acti

  6. ruby - 趋势算法 - 2

    我正在开发一个类似微论坛的项目,其中一个特殊用户发布一条快速(接近推文大小)的主题消息,订阅者可以用他们自己的类似大小的消息来响应。直截了当,没有任何形式的“挖掘”或投票,只是每个主题消息的响应按时间顺序排列。但预计会有很高的流量。我们想根据它们引起的响应嗡嗡声来标记主题消息,使用0到10的等级。在谷歌上搜索了一段时间的趋势算法和开源社区应用示例,到目前为止已经收集到两个有趣的引用资料,但我还没有完全理解它们:Understandingalgorithmsformeasuringtrends,关于使用基线趋势算法比较维基百科页面浏览量的讨论,在SO上。TheBritneySpearsP

  7. Ruby - 不支持的密码算法 (AES-256-GCM) - 2

    我收到错误:unsupportedcipheralgorithm(AES-256-GCM)(RuntimeError)但我似乎具备所有要求:ruby版本:$ruby--versionruby2.1.2p95OpenSSL会列出gcm:$opensslenc-help2>&1|grepgcm-aes-128-ecb-aes-128-gcm-aes-128-ofb-aes-192-ecb-aes-192-gcm-aes-192-ofb-aes-256-ecb-aes-256-gcm-aes-256-ofbRuby解释器:$irb2.1.2:001>require'openssl';puts

  8. java实现Dijkstra算法 - 2

    文章目录一.Dijkstra算法想解决的问题二.Dijkstra算法理论三.java代码实现一.Dijkstra算法想解决的问题解决的问题:求解单源最短路径,即各个节点到达源点的最短路径或权值考察其他所有节点到源点的最短路径和长度局限性:无法解决权值为负数的情况二.Dijkstra算法理论参数:S记录当前已经处理过的源点到最短节点U记录还未处理的节点dist[]记录各个节点到起始节点的最短权值path[]记录各个节点的上一级节点(用来联系该节点到起始节点的路径)Dijkstra算法步骤:(1)初始化:顶点集S:节点A到自已的最短路径长度为0。只包含源点,即S={A}顶点集U:包含除A外的其他顶

  9. 对于体育新闻中文文本关键字提取有哪些关键字提取算法及其步骤 - 2

    对于体育新闻中文文本的关键字提取,常用的算法包括TF-IDF、TextRank和LDA等。它们的基本步骤如下:1.TF-IDF算法: -将文本进行分词和词性标注处理。-统计每个词在文本中的词频(TF)。-计算每个词在整个语料库中出现的文档频率(DF)和逆文档频率(IDF)。-计算每个词的TF-IDF值,并按照值的大小进行排序,选择排名前几的词作为关键字。2.TextRank算法:-将文本进行分词和词性标注处理。-将分词结果转化成图模型,每个词语为节点,根据词语之间的共现关系建立边。-对图模型进行迭代计算,计算每个节点的PageRank值,表示该节点的重要性。-选择排名前几的节点作为关键字。3.

  10. arrays - ruby 中的最佳排列计数算法 - 2

    我正在尝试计算由二进制形式的1和0的P数表示的数字的数量。如果P=2,则表示的数字为0011、1100、0110、0101、1001、1010,所以计数为6。我试过:[0,0,1,1].permutation.to_a.uniq但这不是大数的最佳解决方案(P可以什么可能是最好的排列技术,或者我们是否有任何直接的数学来做到这一点? 最佳答案 Numberofpermutationcanbecalculatedusingfactorial.a=[0,0,1,1](1..a.size).inject(:*)#=>4!=>24要计算重复项,

随机推荐