1、共识基础

人们对共识机制的研究其实由来已久,从上世纪70年代就开始了相关研究,其目的是为了解决分布式系统中的一致性问题。Fischer, Lynch 和 Patterson在1985年发表的论文中提出了可以说是最重要的分布式系统定理:FLP不可能定理(在异步通信场景,即使只有一个进程失败,也没有任何算法能保证非失败进程达到一致性);2000年,EricBrewer教授又进一步提出了CAP猜想:一致性、可用性和分区容错性三者无法在分布式系统中被同时满足,并且最多只能满足其中两个;2002年,Lynch与其他人证明了Brewer的猜想,从而把CAP上升为一个定理。这期间和之后,涌现了一些著名的分布式一致性算法,如LeslieLamport在1989年提出的Paxos算法,1999年Castro和Liskov提出的PBFT算法等。直到比特币采用POW进行记账后,共识算法才真正进入到了大众的视野里。

一般来说根据处理的异常情况不同,可以把共识算法分为两种类型,一种是针对非拜占庭错误的,这类算法性能较高,但容错性较差,如Paxos、Raft等;另一种是针对拜占庭错误的,这类算法往往容错性较高,但是性能相对较差,包括工作量证明(POW)、权益证明(POS)、委托权益证明(DPOS)、实用拜占庭容错算法(PBFT)等。处理拜占庭错误的算法有两种思路,一种是通过提高作恶成本以降低作恶节点出现的概率,如工作量证明、权益证明等,其中工作量证明是通过算力,而权益证明则是通过持有权益。另外一种是在允许一定的作恶节点存在的前提下,依然使得各节点之间达成共识,如实用拜占庭容错算法等。下面我们就来讲讲目前存在的主流共识算法。

2、拜占庭将军问题

1982年,Leslie Lamport等科学家提出了著名的拜占庭将军问题(Byzantine failures),其讨论的是允许存在少数节点作恶场景下的一致性达成问题。简单描述下: 国土辽阔的拜占庭帝国,基于防御目的,将每支军队分别部署在全国各地。因为距离遥远,将军们只能靠信差传递消息。战争爆发时,拜占庭帝国军队的将军们必须全体一致的决定是否攻击某一支敌军,以获取作战胜利。然而将军们无法确定他们中是否存在叛徒,叛徒可能擅自变更进攻意向或者进攻时间,以破坏进攻的一致性,致使作战失败。在这种状态下,拜占庭将军们该商定一种怎样的远程沟通办法,以达到一致呢?


论文中指出,对于拜占庭问题来说,假如节点总数为N,叛变将军数为F,则当N≥3F+1时,问题才有解,由拜占庭容错算法BFT进行保证。简单说一下论证过程:假设节点总数为N,作恶节点总数为F,有效的善良节点数为L1,无效(发生故障)的善良节点数为L2; 那么系统要安全的达成一致则必须满足2点:有效的善良节点超过作恶节点,同时也必须超过故障的善良节点。转化为数学公式则:L1≥F+1,L1≥L2+1(L2=F),又L1=N-L2-F,即N-F-F≥F+1,得出N≥3F+1;因此当叛变者不超过1/3时,存在有效的拜占庭容错算法。但BFT一直存在复杂度过高的问题,并没有真正落地到实际场景中。

Miguel Castro和Barbara Liskov在1999年提出了实用拜占庭容错算法PBFT(Practical Byzantine Fault Tolerance),以解决原始拜占庭容错算法效率不高的问题,将算法复杂度大为降低,使得拜占庭容错算法在实际系统应用中变得可行。PBFT是针对状态机副本复制为主的分布式系统执行环境开发的算法,旨在让系统中大部分的诚实节点来覆盖恶意节点或无效节点的行为。其运作步骤为: (1)随机取一个副本作为主节点,其他的副本作为备份; (2)用户端向主节点发送使用服务操作的请求; (3)主节点通过广播将请求发送给其他副本; (4)所有副本执行请求并将结果发回用户端; (5) 用户端需要等待F+1个不同副本节点发回相同的结果,作为整个操作的最终结果。PBFT算法要求系统的失效节点数量不得超过全网节点的1/3,容错率相对较低。

3、PoW:工作量证明机制

比特币的区块链网络在设计时,针对PBFT中同时存在多个提案和最终一致性确认的问题进行了创造性的改进,提出并采用了PoW算法。通过消耗大量能源来计算一个满足条件的Hash值来获得记账权(发起提案),某个节点成功找到满足条件的Hash值之后,会马上对全网进行广播打包区块,网络中的节点收到区块后,会立刻对其进行验证。如果验证通过,则表明已经有节点成功记账,自己就不再竞争当前的区块,而是选择接受这个区块,记录到自己的账本中,然后进行下一个区块的竞争记账。同时记账节点会得到代币奖励,进而吸引更多节点参与竞争。假如节点有任何的作弊行为,都会导致验证不通过,并直接丢弃其打包的区块,作弊的节点不但得不到奖励,还损失了巨大挖矿成本。这样全网节点始终维护着拥有最大工作量的链,从而保证整个账本的相对一致性。

PoW算法简单来说就是算力越大,记账成功率越高(干的越多,获得越多)。其实现了完全去中心化,节点可以自由进出且实现简单。同时其容错性方面得到了提升,允许全网50%的节点出错,破坏系统需要投入极大的成本。它的缺点也很明显,首当其冲便是浪费能源,其次是共识效率低下,并且存在算力集中的风险。目前很难满足商业化应用的需求,典型项目如比特币。

4、PoS:权益证明机制

PoS也称股权证明机制,其诞生的初衷是为了解决PoW带来的能耗问题。这种模式下持有币的数量越多、时间越长,记账成功率就越高(持有越多,获得越多),类似于利息制度。举例来说,PoS算法中有一个名词叫币龄,每个币每天产生1币龄,如果你持有100个币,总共持有了30天,那么此时你的币龄就为3000。这个时候如果你发现了一个PoS区块,你的币龄就会被清空为0。你每被清空365币龄,你将会从区块中获得0.05个币的奖励(相当于年利率5%),在这个案例中,奖励 = 3000 * 5% / 365 = 0.41个币,即持币有利息。

PoS作为PoW的一种升级共识机制,根据每个节点所持有代币的数量和时间,等比例的降低挖矿难度,在一定程度上缩短了共识达成的时间,但最重要的是不再需要消耗大量能源进行挖矿。它的缺点在于:性能提升有限,持币吃息的模式会导致代币的大量集中,流动性变得匮乏起来。典型项目如以太坊,目前正在从PoW切换至PoS机制。

5、DPoS:委托权益证明机制

DPoS是权益证明的一种改进版本,共识过程不再需要所有参与节点进行验证,而是委托部分代表来进行,很大程度上提高了共识效率。BitShares社区首先提出了DPoS机制,并引入了见证人的概念。见证人可以生成区块(记账并获得奖励),每一个持有比特股的人都可以投票选举见证人。得票数前100名的候选者可以当选为见证人,见证人的候选名单每个维护周期更新一次。见证人通过随机排列后,依次轮流生成区块(限时2s内出块),若见证人在2s内未能出块,则自动跳到下一个见证人。由于持股人可以随时通过投票更换见证人,因此见证人为了获得奖励和避免损失保证金,就必须提供稳定高效的出块能力。

可以看出,DPoS实际上是对共识进行了分级,先通过投票选举达成见证人共识(选出极少数可信的见证人),然后见证人之间再达成交易验证共识,这样大大提高了整个系统的共识效率。从某种角度来看,DPoS与议会制度或人民代表大会制度有相似之处。如果代表不能履行他们的职责,例如未能按时出块,就会被网络选出的新见证节点所取代。DPoS算法从性能和能耗的角度来说完全可以满足商用,但也不可避免地带来了过于中心化的问题。比如现在很火的EOS超级节点竞选就变成了鲸鱼们的合纵游戏,甚至被质疑是伪区块链项目。当然这种看法笔者并不赞同,毕竟上期也讲到3类区块链,采用DPoS算法的项目应当算作联盟链,只不过有些联盟比较开放有了大量散户,从运营模式上看更像公链。

6、其它共识机制

Paxos和Raft是另外两种经典的共识算法,准确的说应该是分布性一致算法,它们都是为了解决非拜占庭问题下实现分布式系统数据一致性的问题(主要防范节点故障,而非节点作恶)。这个过程如同选举一样,参选者需要说服大多数选民(服务器)投票给他,一旦选定后就跟随其操作。Paxos和Raft的区别在于选举的具体过程不同,有兴趣的读者可以自行了解下。

7、共识的价值

共识机制解决了区块链如何在分布式场景下达成一致性的问题,通过算法创造了信任,从而极大地减少当前金融系统及其他社会系统中的信用成本。小到菜市场的价格形成,大到一个国家的建立,这背后都意味着一种共识,所以共识本身就是价值,但价值大小要看其运用的场景。回过头来再看看市场上充斥着的价格混杂的各种数字货币,它们落地时的用途才真正决定着其价值,思考清楚了再入场不迟,当然纯投机的话可以完全不用考虑。现阶段并没有完美的共识机制,每种算法差异的背后都是对性能效率和去中心化不同的取舍。随着区块链应用场景的不断扩展,未来必然会不断涌现出新的共识算法,或许某一天会诞生出具有普适性的算法,给人类社会带来深层次的变革。

共识与拜占庭将军问题相关推荐

  1. 区块链:3、共识算法 拜占庭将军问题

    区块链:3.共识算法 拜占庭将军问题 区块链系统采用分布式共识算法在无中心节点控制,又可能存在破坏节点的环境下确立系统状态,从而建立信任.区块链因此也被称为信任机器. 共识算法因不同的应用场景而有所不 ...

  2. 【分布式共识二】拜占庭将军问题----口头协议

    拜占庭将军问题是一个共识问题: 首先由Leslie Lamport与另外两人在1982年提出,被称为The Byzantine Generals Problem或者Byzantine Failure. ...

  3. 【笔记】拜占庭将军问题与共识算法

    一.拜占庭将军问题 1.概念.实质与条件   拜占庭将军问题的核心:军中可能有叛徒,军队保证进攻一致性的同时,又要避免军中叛徒的破坏. 在拜占庭将军问题中,将军们必须有一个预定的方法,使所有忠诚的将军 ...

  4. 学习区块链,绕不过去的“拜占庭将军问题”!!这里正好有通俗易懂的解释

    "拜占庭将军问题"维基百科: 拜占庭将军问题(Byzantine Generals Problem),是由莱斯利·兰波特在其同名论文中提出的分布式对等网络通信容错问题.在分布式计算 ...

  5. 分布式基础-拜占庭将军问题

    一 背景 拜占庭将军问题是如何通过通讯方式来达成共识的问题,Leslie Lamport 来借助这个问题说明如何在分布式环境下达成共识. 拜占庭将军问题是这样的:拜占庭帝国的军队在围攻一座城市,拜占庭 ...

  6. 拜占庭将军问题与PBFT算法和POW共识

    1 拜占庭将军问题 Leslie Lamport(莱斯利·兰波特)在论文<The Byzantine Generals Problem>提出拜占庭将军问题: 一组拜占庭将军分别各率领一支军 ...

  7. 拜占庭将军问题和 Raft 共识算法讲解

    在分布式系统中, 什么是拜占庭将军问题?产生的场景和解决方案是什么?什么是 Raft 共识算法?Raft 算法是如何解决拜占庭将军问题的?其核心原理和算法逻辑是什么?除了 Raft,还有哪些共识算法? ...

  8. 分布式协议与算法实战——拜占庭将军问题:有叛徒的情况下,如何才能达成共识?(笔记)

    拜占庭将军问题(The Byzantine Generals Problem),其实是借拜占庭将军的故事展现了分布式共识问题,还探讨和论证了解决的办法.实际上,它是分布式领域最复杂的一个容错模型,一旦 ...

  9. 拜占庭将军问题与区块链共识算法PBFT

    概述 1.两军问题 两军问题中信道是不可靠的,并且其中没有叛徒之说. 解决方式:Tcp的三次握手可以提供相对可靠地信道通信. 2.拜占庭将军问题 概述 拜占庭将军问题中并不去考虑通信兵是否会被截获或无 ...

最新文章

  1. phonegap+emberjs+python手机店发展,html5实现本地车类别~
  2. 可变和不可变的数据类型
  3. HDU 1693(状态压缩 插头DP)
  4. graphpad做饼图_如此简单的饼图,这些点你可能还不知道
  5. 通过SSIS的“查找”组件进行不同数据源之间数据的合并操作
  6. Jenkins 从选择插件到配置详解-Gradle
  7. 会动的图解 (二) 怎么让goroutine跑一半就退出?
  8. 织梦5.7生成HTML很慢,Dedecms 生成静态网页速度特别慢的问题
  9. Mysql的int和bigint字段类型,映射到Java的Integer和Long类型时,勾选UNSIGNED无符号会导致越界转换。
  10. H2最完整的资料下载地址:
  11. 网站域名备案时需要什么资料
  12. format函数_Python学习教程:Python3之字符串格式化format函数详解(上)
  13. NAT-PT (Network Address Translation-Protocol)网络地址转换协议转换
  14. thymeleaf学习笔记
  15. HP ProLiant DL380 G6内存错误导致WHEA-Logger 47报警的解决
  16. rk板子linux系统安装rga,drm,mpp
  17. 华为 荣耀20 Andorid10 图片保存到相册 图片不刷新问题
  18. 关于win7下r3窗口进程保护的一些方式
  19. IDEA中出现乱码的处理
  20. Web全栈~10.流程控制

热门文章

  1. spark Standalone
  2. 数据冒险之顺序表应用
  3. 直播:「青葱创业计划」发布会
  4. js-ajax/axios的拦截器
  5. CSS入门保姆级知识整理!!看到就是赚到!(1)
  6. 【JS与JQ】原生JS(clientTop/clientLeft,offsetTop/offsetLeft,scrollTop/scrollLeft)
  7. 什么是web3 | 区块链web3.0人才
  8. 代码保护软件VMP逆向分析虚拟机指令
  9. 缘起:BigTable
  10. 为什么计算机桌面图标不见了,桌面上的图标不见了怎么办(电脑桌面图标突然没了怎么办?简单三步教你解决)...