PBFT共识算法

最新推荐文章于 2024-04-24 09:42:15 发布
最新推荐文章于 2024-04-24 09:42:15 发布
阅读量555 收藏
点赞数
分类专栏： 共识算法
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/kfsah/article/details/117997934
版权

PBFT共识算法

PBFT包括两个主要的工作流程

  1. 网络环境良好情况下的正常工作模式(网络节点都同步 而且 leader运行正常)
  2. 用于更换崩溃leader的view-change模式

正常工作模式

正常工作模式，包含三个子协议 Pre-Prepare,Prepare,Commit.

  1. 当leader收到客户端的transaction时，根据transaction广播pre-prepare消息。
  2. 收到pre-prepare消息的节点，广播prepare消息。
  3. 当节点收到2f个preprare消息时，广播commit消息。
  4. 当节点收到2f+1个commit消息时，处理transaction。

view-change模式

当正常工作模式出现超时，共识发生停滞的时候。节点会更换至view-change模式。并将节点本地的view-number++，同时广播view-change消息

如果节点的正常工作模式没有出现超时，但是收到了f+1个view-change消息。也会切换到view-change模式，并将节点本地的view-number++，同时广播view-change消息。

view-change工作模式规定新的leader为 view-change消息的heightmod 节点总数N。因此新的leader的转换过程，是在节点集合中循环的。

当节点发现自己就是新的view的leader，而且收到了2f+1个view-change消息时，广播NEW_VIEW消息。收到的2f+1个view-change消息被组合起来作为NEW-VIEW消息的proof。

当节点接收到一个 number大于等于自己当前view-number的NEW-VIEW消息时，更新自己的view-number到NEW-VIEW消息的number。

如果节点收到的NEW-VIEWnumber小于自己的当前number,则忽略。

节点进入view-change模式后，维护一个timeout计时器。 每一次view-change工作模式的失败(例如超时，即在timeout时间内收不到NEW-VIEW消息）都会使timeout计时器的超时时间翻倍。

对PBFT的攻击

背景

  1. Andrew Miller 设计了新的共识 HoneyBadgerBFT，论文中提到了BFT共识严重依赖时序假设，所造成的脆弱性。 在论文的附录中，Andrew Miller 介绍了BFT的攻击方法，本文将对该方法进行翻译和介绍。
  2. 另外本文不再对BFT的时序脆弱性进行论证，详情可见HoneyBadgerBFT的英文论文或者 中文论文。

断断续续的正常工作模式将会阻碍PBFT

我们会设计一个恶意的proxy调度器。拦截并延迟发给leader的消息。

下图展示了攻击的整个过程 其中 〇 后面的消息是该列表示的节点向外发出的消息 • 后面的消息是该列表示的节点接受到的消息 ❌表示收到的消息view已经过时，因而忽略。 红色区域表示 延时发送 粉色区域表示 延时接受 在每一格的右下角会标注该列节点所处的 view
!
从图中我们可以看出。 第一阶段 client向0,1,2,3四个节点发出Req。 作为leader节点的0 向外发出PP 准备挖矿 但是这个PP为攻击者抑制住了 所有节点在∆时间内 没有收到PP，便误认为是leader崩溃，进入view-change模式

第二阶段 节点0123进入view-change模式 节点0123向外发出V1，试图更换view，试图将leader更换为1 这时候，攻击者抑制节点1接受V1消息 使得节点023更新到了view1，同时leader也变成了节点1 只有节点1没有收到V1,于是等待大家推选出新的leader

第三阶段 节点1接收到了刚刚被攻击者抑制的V1消息，发现大家选了自己作为leader 于是向外宣布就职，发出消息N1PP1 节点023由于没有在阶段2的时间内收到N1PP1，以为节点1已经崩溃，无法胜任leader。故向外发送V2宣布，继续大选。 节点1收到了V2，发现自己错过了就职时间，很遗憾，只能附和V2.继续推选其他leader。 此时攻击者抑制节点2接受V2消息。 截止当前 节点013都认为节点2是新的leader 只有身为leader的节点2还不知情，继续等待大家选举leader

第四阶段 由于没有收到leader发出的就职消息，大家以为节点2已经崩溃。于是发起新的大选V3 节点2也在收到V2后又收到V3，发现自己已经错过了就职时间。很遗憾但是只能附和V3

不断循环上述过程，所有矿工都陷入无尽的大选循环当中，而不从事任何劳动。导致共识停滞。

总结
只要攻击者能抑制第一个leader发出PP,并顺次抑制其他leader接收Vn 整个网络中的共识就会永久停滞。

资料

  1. 知乎：HoneyBadger-BFT核心:PBFT时间敏感性及其攻击方法
    https://zhuanlan.zhihu.com/p/161629554
sweetfig180
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
代码实现pbft共识算法，并进行Demo展示
qq_35911184的博客
12-10 8708
参考资料： https://www.jianshu.com/p/fb5edf031afd https://www.cnblogs.com/gexin/p/10242161.html 本demo为pbft共识算法的代码实现，如果想了解pbft的详细信息请自行浏览参考资料 本demo展示了pbft的部分功能（没有写主节点轮循机制），写的并不严谨，仅作为对pbft的了解用途 实现功能： ...
PBFT算法
热门推荐
landai2011的专栏
08-21 1万+
PBFT算法PBFT算法 算法前置 算法介绍算法前置State Machine Replication State Machine Replication是一项很有效的fault tolerance技术。在这个模型中，程序（比如一个apache server）被视为 deterministic state machine ，意思就是给程序一定顺序的 input requests ，程序执行后就会到
区块链核心：共识算法
05-15
​什么是共识算法背景分布式系统集群设计中面临着一个不可回避的问题，一致性问题对于系统中的多个服务节点，给定一系列操作，如何试图使全局对局部处理结果达成某种程度的一致？这个一致性问题大致有如下的场景：节点之间通讯不可靠的，延迟和阻塞节点的处理可能是错误的，甚至节点自身随时可能宕机节点作恶举例说明，就比如有两家电影院同时售卖总量一定的电影票，在这样的场景下，要如何设计方式来保证两家电影院协调同步不出现超卖或者错卖的问题呢？共识算法，就是解决对某一提案（目标，投票等各种协作工作），大家达成一致意见的过程比如上述的买票问题，就可以有如下的设计：1.每次卖票打电话给其他电影院，确认当前票数2.协商售卖时间，比如一三五A卖，二四六B卖3.成立个第三方存票机构，它统一发票通过以上的设计，可以看出一个很重要的解决一致性算法的解决思路，即：将可能引发不一致的并行操作进行串行化，就是现在计算机系统里处理分布式一致性问题基础思路和唯一秘诀 著名的共识设计理论FLP 不可能性原理  共识算法的理论下限提出该定理的论文是由 Fischer, Lynch 和 Patterson 三位作者于 1985 年发表，该论文后来获得了 Dijkstra（就是发明最短路径算法的那位）奖。FLP 原理认为对于允许节点失效情况下，纯粹异步系统无法确保一致性在有限时间内完成。三人三房间投票例子三个人在不同房间，进行投票（投票结果是 0 或者 1）。三个人彼此可以通过电话进行沟通，但经常会有人时不时地睡着。比如某个时候，A 投票 0，B 投票 1，C 收到了两人的投票，然后 C 睡着了。A 和 B 则永远无法在有限时间内获知最终的结果。如果可以重新投票，则类似情形每次在取得结果前发生带入到计算机领域就是说，即便在网络通信可靠情况下，一个可扩展的分布式系统的共识问题的下限是无解。即可靠性的下限是0%CAP  分布式系统领域的重要原理CAP 原理最早由 Eric Brewer 在 2000 年，ACM 组织的一个研讨会上提出猜想，后来 Lynch 等人进行了证明• C（一致性）：所有的节点上的数据时刻保持同步，即数据一致• A（可用性）：每个请求都能在一定时间内接受到一个响应，即低延迟• P（分区容错）：当系统发生分区时仍然可以运行的定理：任何分布式系统只可同时满足二点，没法三者兼顾。即数据一致，响应及时，可分区执行不可能同时满足。举个例子：一个分布式网路上，某一个节点有一组依赖数据A，当网络无延迟，无阻塞时，依赖于X的操作可正常进行。但网络无延迟阻塞在现实世界中是没法100%保证的，那么当网络异常时，必然会产生分布式系统的分区和孤岛，那当一个执行操作在A分区之外时，如果要保证P,即当系统发生分区时仍可运行，就需要在分布式系统中多个节点有X的备份数据，以应对分区情况。则这时候就需要在C,A之间做出选择。假如选择C，即要保证数据在分布式网络中的一致性，那么就需要在X每次改动时，需要将全网节点的X数据同步刷新成最新的状态，那么在等待数据刷新完成之前，分布式系统是不可响应X的依赖操作的，即A的功能缺失假如选择A，即要突出低延迟的实时响应。那么在响应的时候，可能全节点的X数据并没有同步到最新的状态，则会导致C的缺失。上面看上去有些绕，那么你只要记住这句话，CAP原理在分布式网络系统的应用讨论，其实就是讨论在允许网络发生故障的系统中，该选择一致性还是可靠性？如果系统重视一致性，那么可以基于ACID原则做系统设计即 Atomicity（原子性）、Consistency（一致性）、Isolation（隔离性）、Durability（持久性）。ACID 原则描述了对分布式数据库的一致性需求，同时付出了可用性的代价。• Atomicity：每次操作是原子的，要么成功，要么不执行；• Consistency：数据库的状态是一致的，无中间状态；• Isolation：各种操作彼此互相不影响；• Durability：状态的改变是持久的，不会失效相应的有一个BASE原则，（Basic Availiability，Soft state，Eventually Consistency）则强调了可用性。 经典的共识算法设计业内，针对节点异常的情况，会有两种分类1.故障的，不响应的节点，成为非拜占庭错误2.恶意响应的节点，称为非拜占庭错误Paxos 最早的共识算法  非拜占庭算法的代表Paxos有三种角色：• proposer：提出一个提案，等待大家批准为结案。客户端担任该角色；• acceptor：负责对提案进行投票。往往是服务端担任该角色；• learner：被告知结案结果，并与之统一，不参与投票过程。即普通节点系统运行由proposer驱动，当合法提案在一定时间内收到1/2以上投票后达成共识。因此，可得出无法达成共识的条件：1.proposer故障2.二分之一以上acceptor故障拜占庭问题与BFT(Byzantine Fault Tolerant) 算法Leslie Lamport 1982 年提出用来解释一致性问题的一个虚构模型。拜占庭是古代东罗马帝国的首都，由于地域宽广，守卫边境的多个将军（系统中的多个节点）需要通过信使来传递消息，达成某些一致的决定。但由于将军中可能存在叛徒（系统中节点出错），这些叛徒将努力向不同的将军发送不同的消息，试图会干扰一致性的达成。拜占庭问题即为在此情况下，如何让忠诚的将军们能达成行动的一致。对于拜占庭问题来说，假如将军总数为 N，叛变将军数为 F，则当N>=3F+1 时，问题才有解，即叛变的将军不超过1/3时，存在有效的算法，如BFT，不论叛变者如何折腾，忠诚的将军们总能达成一致的结果。这是一个数学论证的结论，有兴趣的同学可以自行推导。PBFT  一种高效拜占庭容错共识算法PBFT是Practical Byzantine Fault Tolerance的缩写，意为实用拜占庭容错算法。该算法是Miguel Castro 和Barbara Liskov（2008年图灵奖得主）在1999年提出来的，解决了原始拜占庭容错算法效率不高的问题。他的核心思想是：对于每一个收到命令的将军，都要去询问其他人，他们收到的命令是什么。如上图，假设命令由A将军分发，假如A是作恶异常，分发给B,C,D的操作分别是1,2,3.意图扰乱共识。拜占庭容错算法上设计实现是，当B,C,D收到命令后，相互之间也会沟通从A收到的命令是否一致，从而达到识破干扰的目的。其容错的极限值就是N>=3F+1。PBFT 在区块链上的实现区块链的节点分为记账节点和普通节点两个角色记账节点负责向全网提供记账服务，并维护全局账本，每过一段时间从记账节点中选一个议长，进行命令的分发，其他记账节点则作为议员进行验证将军就是记账节点，拥有全局账本，并验证交易的有效性，过互相传达验证结果，在f共识的一般流程如下：1.任一节点接收到发送者签名的交易数据请求后，向全网广播2.所有记账节点均独立监听全网的交易数据，并记录在内存3.议长在经过t后发送共识请求提案request4.议员在收到提案后，进行相关验证，发送响应response5.任意节点在限定时间内收到至少F+1个response后，共识达成，把交易记录入区块并发布给全网，如果超时，则更换视图和议长6.任意节点在收到完整区块后，把包含的交易从内存中删除开始下一个共识循环区块产生间隔t,    记账节点n,  可容错节点数f， 视图编号v,  区块高度h, 议长编号p,  议员编号i p=(h-v)%n  未来的发展POW算法建立了比特币帝国，具有划时代的意义。但其能耗和速度问题却是制约区块链普及的两大难以解决的问题。目前POS算法是一大趋势，以太坊的Casper，EOS的DPos等都是借鉴了上述前人的设计理念做的基于应用场景的优化改造，但万变不离其宗，我和大家一样，需要不断的学习和思考，没准，能有发明出自己的共识算法的一天呢。 
PBFT 实现：一个高效、可靠的分布式共识框架
最新发布
gitblog_00100的博客
04-24 273
PBFT 实现：一个高效、可靠的分布式共识框架 项目地址:https://gitcode.com/wupeaking/pbft_impl PBFT（Practical Byzantine Fault Tolerance） 是一种经典的共识算法，由麻省理工学院在1999年提出。它为分布式系统提供了高可用性和一致性保障，即使在部分节点出现故障时也能正常运行。现在，我们有了一个由开发者 Wupeakin...
区块链基础：共识算法
11-28
在区块链网络中，谁获得记账权是通过全网节点间所达成的共识来决定的；共识算法即这种“共识”的算法/代码体现；共识算法解决了拜占庭将军问题，即让一群人在彼此不信任的情况下还能在一起自动协调工作；本套课程带你认识常用的共识算法及其代码实现；
PBFT代码实现
qq_31639829的博客
02-10 3651
客户端 var clientCmd = &cobra.Command{ Use: "client", Short: "client manage", Run: func(cmd *cobra.Command, args []string) { // 获取客户端的端口 port, err := cmd.Flags().GetInt("port") if err != nil { log.Println("get param error: ", err) } // 客户端
PBFT算法源码详解
stephen_curry300的博客
08-14 3812
真的好久没有写博客了，正好最近在研究PBFT，那就从PBFT开始写起吧！ 先奉上大佬@byron1st写的PBFT代码：https://github.com/bigpicturelabs/simple_pbft 我会带着大家鹿一遍源代码！因为看到网上好多的博客都是互相抄袭，对大家一点帮助没有 1.服务的启动主函数 func main() { nodeID := os.Args[1] // 这边就是传进来的公司的名称 server := network.NewServer(nodeID) serv.
SPBFT:《一种面向区块链链的优化PBFT共识算法》基础源代码
03-23
一种面向区块链链的优化PBFT共识算法[J]。北京交通大学学报，2019，43（5）：58-。 方伟伟，王自悦，宋慧丽，王云鹏，丁乙。 一种针对区块链的优化PBFT共识算法。 北京交通大学，2019，43（5）：58-。相关领域的研究...
人工智能-项目实践-区块链-基于pbft共识算法的贝壳区块链平台.zip
01-03
人工智能-项目实践-区块链-基于pbft共识算法的贝壳区块链平台 最初是计划学习pbft算法之后对其进行一个Go语言的实现. 编写的过程中发现, 如果想实现PBFT, 需要实现网络通信, 需要加密和验证签名功能. 于是逐渐的就...
blockchain-IoT-PoC:区块链概念python实现的证明，该算法将PBFT共识算法用于物联网配置更新
05-04
区块链物联网 利用PBFT共识算法的区块链的python概念验证实现。 此特定实现专为IoT配置更新而设计。 在本地运行 在本地运行容器之前，请将manageChain.py中的'localIP'变量更改为您的本地IP地址。 然后，只需运行“ docker-compose up” 这仅仅是概念上的证明。 它不打算在实际部署中使用。
PBFT:Go语言实现PBFT算法
05-15
PBFT Go语言实现PBFT算法 下载demo后无法使用IDE运行，需要是用终端(命令行)工具输入指令运行 需要进入到pbft文件夹下，使用命令 & go build main.go然后使用& ./main Apple会有一些输出， 然后新建一个终端再进入到pbft文件夹下，使用命令& ./main MS 然后新建一个终端再进入到pbft文件夹下，使用命令& ./main Google 然后新建一个终端再进入到pbft文件夹下，使用命令& ./main IBM 如果运行的有问题那么关闭那输入为& ./main Google的命令行
一种面向区块链的优化PBFT共识算法.pdf
08-15
一种面向区块链的优化PBFT共识算法 本文介绍了一种面向区块链的优化PBFT共识算法，该算法基于实用拜占庭容错算法（Practical Byzantine Fault Tolerance，PBFT），旨在解决当前区块链系统中存在的资源浪费和共识...
一种面向区块链的优化PBFT共识算法1
08-04
该优化PBFT共识算法通过积分机制、一致性协议优化和升降级机制，成功地解决了传统PBFT算法在资源消耗和效率上的不足，提高了区块链系统的整体性能。这样的改进对于区块链技术在大规模应用中的推广有着积极的意义，有...
Hyperledger Fabric的PBFT源码分析（一）
Hacker的博客
12-21 1万+
一、PBFT的原理概述 1.算法公式: replicaCount  int 变量定义在pbftCore结构体中 N (N在代码中对应replicaCount整型变量)是所有replicas的集合，每一个replica用一个整数来表示，如{ 0, 1, 2, 3,...N - 1 } N-1 = 3f -----> f = N- 1/3 f 是最大可容忍的出错节点，也就
Java实现基于Socket的pbft算法
毕业作品网站
07-03 654
在这里，大家可能会有个疑惑，为什么进行广播消息不是使用服务端去广播消息，反而是使用 client 一个一个的去广播消息。因为没有购买 t-io 文档，因此我也不知道 server 怎么进行广播消息。因为它取消了学生优惠，现在需要 699￥，实在是太贵了（当然这个贵是针对与我而言的，不过这个框架还是真的挺好用的）舍不得买。为了是思路清晰，client 就是为了请求数据，而 server 就是为了返回数据。这样想的时候，不会是自己的思路断掉。
PBFT算法实现过程
yangwei256的博客
10-20 9581
转载：https://www.jianshu.com/p/2383c7841d41 PBFT算法 三个阶段：预准备（pre-prepare）、准备（prepare）、和确认（commit） 步骤： 从全网节点选举出一个主节点（Leader），新区块由主节点负责生成 Pre-Prepare：每个节点把客户端发来的交易向全网广播，主节点0将从网络收集到需放在新区块内的多个交易排序后存入列...
Golang语言实现PBFT共识算法
09-22
在Go语言中，可以使用Go的标准库以及第三方库来实现PBFT共识算法。 具体实现步骤如下： 1. 定义网络中的节点数量以及角色（例如：主节点，从节点）。 2. 实现请求阶段，即请求节点向其他节点发送请求消息。 3. ...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值