共识算法

区块链中最重要的便是共识算法,比特币使用的是POS(Proof of Work,工作量证明),以太币使用的是POS(Proof of Stake,股权证明)使得算理便的不怎么重要了,而今POS的变体DPOS(Delegated Proof of Stake,股份授权证明)进一步削减算力的浪费,同时也加强了区块链的安全性。
不过,对于不需要货币体系的许可链或者私有链而言,绝对信任的节点,以及高效的需求上述共识算法并不能够提供,因此对于这样的区块链,传统的一致性算法成为首选,PBFT(拜占庭容错)、PAXOS、RAFT。
 

PBFT(拜占庭容错)

基于拜占庭将军问题,一致性的确保主要分为这三个阶段:预准备(pre-prepare)、准备(prepare)和确认(commit)。流程如下图所示:
 
其中C为发送请求端,0123为服务端,3为宕机的服务端,具体步骤如下:
1. Request:请求端C发送请求到任意一节点,这里是0
2. Pre-Prepare:服务端0收到C的请求后进行广播,扩散至123
3. Prepare:123,收到后记录并再次广播,1->023,2->013,3因为宕机无法广播
4. Commit:0123节点在Prepare阶段,若收到超过一定数量的相同请求,则进入Commit阶段,广播Commit请求
5.Reply:0123节点在Commit阶段,若收到超过一定数量的相同请求,则对C进行反馈
 
根据上述流程,在 N ≥ 3F + 1 的情況下一致性是可能解決,N为总计算机数,F为有问题的计算机总数
 
N=4 F=0 时:
  得到数据 最终数据
A 1 1 1 1 1
B 1 1 1 1 1
C 1 1 1 1 1
D 1 1 1 1 1
N=4 F=1 时:
  得到数据 最终数据
A 1 1 1 0 1
B 1 1 0 1 1
C 1 0 1 1 1
D 0 1 1 1 1

N=4 F=2 时:
  得到数据 最终数据
A 1 1 0 0 NA
B 1 0 0 1 NA
C 0 0 1 1 NA
D 0 1 1 0 NA
由此可以看出,拜占庭容错能够容纳将近1/3的错误节点误差,IBM创建的Hyperledger就是使用了该算法作为共识算法。
 

PAXOS

PAXOS是一种基于消息传递且具有高度容错特性的一致性算法。
 
算法本身用语言描述极其精简:
phase 1
a) proposer向网络内超过半数的acceptor发送prepare消息
b) acceptor正常情况下回复promise消息
phase 2
a) 在有足够多acceptor回复promise消息时,proposer发送accept消息
b) 正常情况下acceptor回复accepted消息
PAXOS中有三类角色Proposer、Acceptor及Learner,主要交互过程在Proposer和Acceptor之间,做成图便如下图所示:
 
其中1,2,3,4代表顺序。
 
以下图描述多Proposer的情况,T代表时间轴,图中仅画全一个Proposer与Acceptor的关系:
 
A3在T1发出accepted给A1,然后在T2收到A5的prepare,在T3的时候A1才通知A5最终结果(税率10%)。这里会有两种情况:
1. A5发来的N5小于A1发出去的N1,那么A3直接拒绝(reject)A5
2. A5发来的N5大于A1发出去的N1,那么A3回复promise,但带上A1的(N1, 10%)
最终A5也会接受10%
 
 
上图描述,如果已经Promise一个更大的N,那么会直接Reject更小的N
 
 
上述描述了,即使Promise了一个N,如果在未Accepted前,再收到一个更大的N,那么依旧会Reject那个即使已经Promise的N
 
总流程图氪概括如下:
 
 
PAXOS协议用于微信PaxosStore中,每分钟调用Paxos协议过程数十亿次量级。

RAFT

RAFT核心思想很容易理解,如果数个数据库,初始状态一致,只要之后的进行的操作一致,就能保证之后的数据一致。由此RAFT使用的是Log进行同步,并且将服务器分为三中角色:Leader,Follower,Candidate,相互可以互相转换。
RAFT从大的角度看,分为两个过程:
1. 选举Leader
2. Leader生成Log,并与Follower进行Headbeats同步
 

选举Leader

Follower自增当前任期,转换为Candidate,对自己投票,并发起RequestVote RPC,等待下面三种情形发生;

1. 获得超过半数服务器的投票,赢得选举,成为Leader
2. 另一台服务器赢得选举,并接收到对应的心跳,成为Follower
3. 选举超时,没有任何一台服务器赢得选举,自增当前任期,重新发起选举

 

同步日志

Leader接受客户端请求,Leader更新日志,并向所有Follower发送Heatbeats,同步日志。所有Follwer都有ElectionTimeout,如果在ElectionTimeout时间之内,没有收到Leader的Headbeats,则认为Leader失效,重新选举Leader
 
流程图示:
 
 

安全性保证

1. 日志的流向只有Leader到Follower,并且Leader不能覆盖日志
2. 日志不是最新者不能成为Candidate
 
动画演示RAFT:http://thesecretlivesofdata.com/raft/
 

总结

以上三种一致性算法仅仅只是核心思路而已,如果要具体实现当然还有很多方面需要进一步的完善。以上三种算法都可以作为区块链的共识算法,并且部分公司已经开始使用,不过最出名的还应属IBM的Hyperledger使用的PBFT共识算法。
 
 
 
  得到数据 最终数据
A 1 1 1 1 1
B 1 1 1 1 1
C 1 1 1 1 1
D 1 1 1 1 1

---------------------
作者:傲慢灬
来源:CSDN
原文:https://blog.csdn.net/jerry81333/article/details/74303194?utm_source=copy
版权声明:本文为博主原创文章,转载请附上博文链接!

区块链共识算法 PBFT(拜占庭容错)、PAXOS、RAFT简述的更多相关文章

  1. [区块链] 共识算法之争(PBFT,Raft,PoW,PoS,DPoS,Ripple)

    近几天对区块链中几种常见的共识机制(PBFT,Raft,PoW,PoS,DPoS,Ripple)进行了总结.尽量使用简单易懂语言,篇幅较大,想了解的可以只读每个算法介绍中前边的原理.本篇文章主要参考& ...

  2. [转帖][区块链]共识算法(POW,POS,DPOS,PBFT)介绍和心得

    [区块链]共识算法(POW,POS,DPOS,PBFT)介绍和心得 置顶 2017-03-12 18:31:19 乐扣老师lekkoliu 阅读数 127953  收藏 更多 分类专栏: 技术管理 区 ...

  3. 区块链共识算法|RAFT和PBFT的区别

    这里有个很形象的比喻: 一个团队一定会有一个老大和普通成员.对于 raft 算法,共识过程就是:只要老大还没挂,老大说什么,我们(团队普通成员)就做什么,坚决执行.那什么时候重新老大呢?只有当老大挂了 ...

  4. (转)区块链共识机制分析——论PoW,PoS,DPos和DAG的优缺点

    近期,随着区块链技术在社区中的声音越来越大,业界已经开始从技术角度对区块链进行全方位的解读.作为第一批区块链技术的实现,传统比特币与以太坊在共识机制.存储机制.智能合约机制.跨链通讯机制等领域并没有非 ...

  5. 老K漫谈区块链的共识(3)——分布式系统和区块链共识

    1. 啥是分布式系统 当我们评价一个新的事物或者介绍一个新的技术的时候,我们不能架空历史和环境,新的事物不可能脱离历史和环境凭空诞生.任何新的事物和新的技术总是或多或少的,与旧的事件以及过去的技术有所 ...

  6. 区块链共识机制:POW、POS、DPOS、PBFT、POOL

    共识机制作为区块链的关键技术之一,在业务吞吐量.交易速度.不可篡改性.准入门槛等等方面发挥重要的作用. 区块链是去中心化的,没有中心记账节点,所以需要全网对账本达成共识.目前有POW.POS.DPOS ...

  7. 区块链共识机制(POW、POS、DPOS等)的优缺点

    一.POW:工作量证明机制 基本原理: 第一代共识机制,比特币的基础.理解起来,很简单,就是“按劳取酬”,你付出多少工作量,就会获得多少报酬(比特币等加密货币).在网络世界里,这里的劳动就是你为网络提 ...

  8. [C#]使用 C# 编写自己的区块链挖矿算法

    [C#] 使用 C# 编写自己区块链的挖矿算法 文章原文来自:Code your own blockchain mining algorithm in Go! ,原始文章通过 Go 语言来实现的,这里 ...

  9. 区块链共识机制之工作量证明(POW)

    像比特币.以太坊.NXT.Bitshares等这些区块链系统,其本质上是一种加密经济组织,它建立在点对点网络上,是去中心化.无管辖的,由密码学.经济学和社会共识来共同维护.这些加密网络因各种原因有着多 ...

随机推荐

  1. 关于db访问层的封装设计感想 dbpy项目的开发

    dbpy dbpy是一个python写的数据库CURD人性化api库.借鉴了 webpy db 和 drupal database 的设计. 如果喜欢 tornado db 或者 webpy db这类 ...

  2. HDU 5487 Difference of Languages

    Difference of Languages Time Limit: 1000ms Memory Limit: 32768KB This problem will be judged on HDU. ...

  3. BNUOJ 2345 Muddy Fields

    Muddy Fields Time Limit: 1000ms Memory Limit: 65536KB This problem will be judged on PKU. Original I ...

  4. var声明的成员变量和函数内声明的变量区别

    1.函数内部,有var声明的是局部变量,没var的,声明的全局变量. 2.在全局作用域内声明变量时,有var 和没var声明的都是全局变量,是window的属性.通过变量var声明全局对象的属性无法通 ...

  5. LA 3890 半平面交

    二分查询答案,判断每一个新形成的向量合在一块能否形成半平面交 #include <iostream> #include <cstdio> #include <cstrin ...

  6. 骑士精神 (codevs 2449)

    题目描述 Description 在一个5×5的棋盘上有12个白色的骑士和12个黑色的骑士, 且有一个空位.在任何时候一个骑士都能按照骑士的走法(它可以走到和它横坐标相差为1,纵坐标相差为2或者横坐标 ...

  7. [NOIP2003] 提高组 洛谷P1040 加分二叉树

    题目描述 设一个n个节点的二叉树tree的中序遍历为(1,2,3,…,n),其中数字1,2,3,…,n为节点编号.每个节点都有一个分数(均为正整数),记第i个节点的分数为di,tree及它的每个子树都 ...

  8. POJ3233:Matrix Power Series

    对n<=30(其实可以100)大小的矩阵A求A^1+A^2+……+A^K,K<=1e9,A中的数%m. 从K的二进制位入手.K分解二进制,比如10110,令F[i]=A^1+A^2+……+ ...

  9. 修改flex chart中Legend的字体样式

    最近在弄FLEX的图表, 发现CHART 中的Legend 的字体通过直接设置Style 并没有办法改变字体大小. google 了下, 发现了这个方法: 通过派生LegendItem类,并设置Leg ...

  10. Codeforces Round #291 (Div. 2) B. Han Solo and Lazer Gun

    因为是x,y均为整数因此对于同一直线的点,其最简分数x/y是相同的(y可以为0,这里不做除法)于是将这些点不断求最简分数用pair在set中去重即可. #include <cmath> # ...