From blockchain consensus back to Byzantine consensus
文章目录
- 1. Pow model
- 2. 一般化的共识问题——拜占庭共识
- 3. 区块链共识算法
- 3.1 有向无环图(DAG: Directed acyclic graph)
- 3.2 分叉(Forks)
- 3.3 主链选择(main branch selection)
- 3.4 区块的决定和交易的确认(Decided blocks and committed transactions)
- 4. Pow区块链的风险
- 5. 区块链拜占庭共识
- 6. 联盟链(blockchain model for consortiums)
The novelty of blockchain is a genuine combination of wellknown research results taken from distributed computing, cryptography and game theory. Its distributed nature guarantees the persistence of the ledger data. Its public key crypto-system offers the capabilities for a user to sign transactions that transfer assets from her account to other accounts. Its incentive mechanisms guarantee that a subset of participants maintain the validity of the transactions. And finally, a Byzantine tolerant consensus protocol aims at guaranteeing the integrity of the ledgers by defining a total order on newly appended blocks of transactions.
区块链的新颖性体现在分布式计算、密码学和博弈论的结合。
- 分布式特性保证了账本数据的永久性。
- 公钥加密系统为用户提供了使用数字签名将资产转移到其他帐户的功能。
- 激励机制确保了参与者子集维持交易的有效性。
- 拜占庭共识协议通过定义新添加的交易区块的顺序来保证账本的正确性。(以前总把integrity翻译成完整性,但是感觉此处应该是“诚实”的意思,指利用拜占庭协议解决共谋、恶意攻击等道德问题。)
1. Pow model
区块链通过pow模型解决共识问题。
2. 一般化的共识问题——拜占庭共识
共识问题的经典定义是指Byzantine failure model/ Byzantine agreement/ Byzantine consensus.
【科普】 拜占庭问题
拜占庭位于如今的土耳其的伊斯坦布尔,是东罗马帝国的首都。由于当时拜占庭罗马帝国国土辽阔,为了达到防御目的,每个军队都分隔很远,将军与将军之间只能靠信差传消息。在战争的时候,拜占庭军队内所有将军和副官必须达成一致的共识,决定是否有赢的机会才去攻打敌人的阵营。但是,在军队内有可能存有叛徒和敌军的间谍,左右将军们的决定又扰乱整体军队的秩序。在进行共识时,结果并不代表大多数人的意见。这时候,在已知有成员谋反的情况下,其余忠诚的将军在不受叛徒的影响下如何达成一致的协议,拜占庭问题就此形成 。
拜占庭假设是对现实世界的模型化,由于硬件错误、网络拥塞或断开以及遭到恶意攻击,计算机和网络可能出现不可预料的行为。
内涵:在缺少可信任的中央节点和可信任的通道的情况下,分布在网络中的各个节点应如何达成共识。
定义:
- Agreement. 协定性. 不会出现两个正确的进程认同两个不同的块。
- Termination. 终止性. 所有正确的进程最终都会有认同的一个块。
- Integrity or Validity. 完整性or 有效性. 确定的块(decided block) 由某个节点产生。如果正确的进程都提议同一个值,那么所有处于认同状态的正确进程都选择该值。完整性可以有一些变化,例如,一种较弱的完整性是认定值等于某些正确经常提议的值,而不必是所有进程提议的值。完整性也隐含了,最终被认同的值必定是某个节点提出过的。
同步(Synchronous):响应时间是在一个固定且已知的有限范围内。
异步(Asynchronous):响应时间是无限的。
FLP Impossibility
在异步网络中,共识是没有办法达成的。简单来说,因为在一个异步系统中,进程可以随时发出响应,所以没有办法分辨一个进程是速度很慢还是已经崩溃,这不满足终止性(Termination)。(Impossibility of distributed consensus with one faulty process)
此时,人们意识到一个分布式共识算法需要具有的两个属性:
- 安全性(safety),安全性意味着所有正确的进程都认同同一个值
- 活性(liveness),活性意味着分布式系统最终会认同某一个值。
每个共识算法要么牺牲掉一个属性,要么放宽对网络异步的假设。
为了绕过FLP Impossibility,能满足大部分情况下都能达成共识。《分布式系统:概念与设计》[6]提到一般有三种办法:
- 故障屏蔽(Fault masking)
- 使用故障检测器(Failure detectors)
- 使用随机性算法(Non-Determinism)。本文重点讨论。把共识的条件放松,只需要足够大的概率保证(probabilistic guarantee)。随机算法的输出不仅取决于外部的输入,还取决于执行过程中的随机概率。因此,给定两个完全相同的输入,该算法可能会输出两个不同的值。随机性算法使得“敌人”不能有效地阻碍达成共识。
和传统选出领导、节点再协作的模式不同,像区块链这类共识是基于哪个节点最快计算出难题来达成的。区块链中每一个新区块都由本轮最快计算出数学难题的节点添加,整个分布式网络持续不断地建设这条有时间戳的区块链,而承载了最多计算量的区块链正是达成了共识的主链(即累积计算难度最大)。比特币使用了 PoW(Proof of Work)来维持共识,一些其它加密货币(如 DASH、NEO)使用 PoS(Proof of Stake),还有一些(如 Ripple)使用分布式账本(ledger)。
但是,这些随机性算法都无法严格满足安全性(safety)。攻击者可以囤积巨量算力,从而控制或影响网络的大量正常节点,例如控制 50% 以上网络算力即可以对 PoW 发起女巫攻击(Sybil Attack。只不过前提是攻击者需要付出一大笔资金来囤积算力,实际中这种风险性很低,如果有这么强的算力还不如直接挖矿赚取收益。
【算法参考文献】
- Randomized Byzantine Generals
- Randomized protocols for asynchronous consensus
- Another advantage of free choice (Extended Abstract): Completely asynchronous agreement protocols)
- Secure and Efficient Asynchronous Broadcast Protocols
- Signature-Free Asynchronous Binary Byzantine Consensus with t < n/3, O(n2) Messages, and O(1) Expected Time
- The Honey Badger of BFT Protocols
在理论上,比特币系统的块如果是无限的,可以认为解决了agreement,但是没有解决termination;从另一个角度来说,如果说比特币保证了termination(例如,在i+ki+ki+k个块挖出时,认为块iii达成了共识),那么agreement不能保证,只能以一定概率满足。
在实际的交易场景中,termination是必须的,通过选择合适的kkk来完成。
所以比特币其实解决的是monte Carlo共识问题。
【蒙特卡洛共识】
是拜占庭共识的变体,agreement放松为probalility agreement.
这种共识可以保证区块链应用能够向客户端(例如商家)返回一个结果,虽然这个结果可能是错的,因为区块链共识并没有承认这个结果的正确性,只是商家可以在预定期间等待预定时间,若在此期间没有发生无效,则认为该交易有效。
3. 区块链共识算法
3.1 有向无环图(DAG: Directed acyclic graph)
保证DAG的两个重要假设:
- Collision-resilience assumption: 哈希函数能够保证每个块的内容是唯一的。
- Unique-pointer-per-block assumption: 每个新块只包含一个哈希值,所以只能指向一个父块。
3.2 分叉(Forks)
对于DAG来说,可能多个子块指向同一个父块。这种情况叫做分叉。
3.3 主链选择(main branch selection)
【比特币】
比特币约每10分钟产生一个新块(全网算力增强,就会增加难度,平均时间控制在10分钟左右)。优点是安全(分叉产生少),缺点是低效。
如果分叉产生了,选择最长的那条作为主链。
交易确认条件:m=5m=5m=5。
【以太坊】
每12-15秒产生一个新块,分叉更容易产生,为了避免算力浪费,选择节点数最多的分叉作为主链(Ghost算法的变Greedy Heaviest Observed Subtree) 。
交易确认条件:m=11m=11m=11。
3.4 区块的决定和交易的确认(Decided blocks and committed transactions)
交易所在的块在主链上,并且后面链接了mmm个块以上。
【比特币】
交易确认条件:m=5m=5m=5。
【以太坊】
交易确认条件:m=11m=11m=11。
4. Pow区块链的风险
因为网络延迟和算力分布不均匀可能导致双花(double spending)问题。
解决办法是根据上述两个影响因素动态调整mmm的数量。但是现有的应用的mmm通常是固定的。
【比特币中的攻击】
- 芬尼攻击(Finney’s attack)
主要通过控制区块的广播时间来实现双花,攻击对象针对的是接受未确认的商家。假设攻击者挖到了区块,在区块中,包含了一笔交易信息,即地址1向地址2转了一定数量的token,不过这两个地址都是攻击者的。但是攻击者并不广播这个区块,而是立即找到一个商家,用他的地址1,把这些token发给商家的地址3。发给商家的交易广播出去后,如果这个商家接受未确认,攻击者就把他自己之前挖到的区块广播出去,这时候发给自己的交易就先于发给商家的交易。对于攻击者来说,通过控制区块的广播时间,就实现了同一笔token的“双花”。一般来说,为了节省时间而接受未确认,特别是对于大额交易而言,是非常不安全的,而且对于大额交易而言,多几次确认,将会降低交易被回滚的风险。 - vector 76 attack
又称“一次确认攻击”,也就是交易确认一次后仍然可以回滚,是 Finney Attack 和 Race Attack 的组合。攻击者创建两个节点,节点 A 连接到商家节点,节点 B 连接到区块链网络中的其他节点。接着,攻击者用同一笔 Token 发起两笔交易,一笔交易发送给商家地址,我们称为交易 1;一笔交易发送给自己的钱包地址,我们称为交易 2。攻击者对交易 2 添加了较高的矿工费从而提高了矿工的打包概率,此时,攻击者并没有把这两笔交易广播到网络中去。接着,攻击者开始在交易 1 所在的分支上进行挖矿,这条分支我们命名为分支 1。攻击者挖到区块后,并没有广播出去,而是同时做了两件事:在节点 A 上发送交易 1,在节点 B 上发送交易 2。由于节点 A 只连接了商家节点,所以当商家节点想把交易 1 传给其它对等节点时,连接了更多节点的节点 B,已经把交易 2 广播给了网络中的大部分节点。于是,从概率上来讲,交易 2 就更有可能被网络认定为是有效的,交易 1 被认定为无效。交易 2 被认为有效后,攻击者立即把自己之前在分支 1 上挖到的区块,广播到网络中。这时候,这个接受一次确认就支付的商家,会确认交易成功,然后攻击者就可以立即变现并转移资产。同时,由于分支 2 连接的更多节点,所以矿工在这个分支上挖出了另一个区块,也就是分支 2 的链长大于分支 1 的链长。于是,分支 1 上的交易就会回滚,商家之前支付给攻击者的交易信息就会被清除,但是攻击者早已经取款,实现了双花。
但是如果商家等待mmm个块,mmm很大,上述两种攻击会变得很困难。但是如果攻击者有超过一半的算力,不管mmm多大,都可以完成攻击。
以太坊通过GHOST协议解决了51%算力的问题,因为不是最长的链是主链,所以即使产生链的速度够快,也不一定能攻击。但是以太坊也有其它问题。
【以太坊中的问题】
- 异常(Blockchain anomaly)。主要原因是decided blocks的重新排列或删除,导致相关联的交易出现异常。因为不管mmm有多大(不是无穷),在m+1m+1m+1时都有出现异常的可能。区块链异常的本质是激励机制不足以使足够多的节点正确挖矿。
- 平衡攻击(balance attack)。攻击中阻断旷工子组之间的通讯,造成信息延迟(message delay),然后在transaction subgroup 中发布交易信息,在另一个block subgroup中挖矿,直到挖到足够多的块,可以有足够高的概率重写主链。该攻击的本质原因是以太坊的主链并不是永久不变的。
5. 区块链拜占庭共识
现有的一致性共识方案效率低下,安全的区块链通常使用现成的算法(例如PBFT,BFTSmart),将经典拜占庭共识问题当作黑盒解决,但只扩展到数十个节点。因此不适用于大型的区块链系统,导致现在的大型区块链系统仍然存在许多安全风险。
【重新定义区块链拜占庭共识问题】
将经典拜占庭共识中的Validity, 改为“判断一个decided block 是否valid 要看它是否满足预设的valid条件。”
DBFT(Democratic BFT,民主-实用拜占庭容错算法)可以解决上述共识问题,参考DBFT: Efficient Byzantine Consensus with a Weak Coordinator and its Application to Consortium Blockchains。
6. 联盟链(blockchain model for consortiums)
共识由预选的节点子集达成。
【联盟链与传统区块链的区别】
- permissioned
- global knowledge. 大多数参与者直到共识决策者的具体名单,因此可以防止女巫攻击(Sybil attack,少数节点控制多个虚假身份进行攻击)。
- Bound on the number of failures. 可以控制恶意节点的个数远小于共识联盟。f<<nf<<nf<<n。
【联盟链与传统区块链的共同点】
- failure model相同,依然要解决联盟内部的拜占庭容错问题。
- communication model相同,消息延迟、中断等问题依然存在。
如果f<n/3f<n/3f<n/3,实用拜占庭容错算法(PBF)可以解决联盟链的拜占庭问题。但是仍由局限性。
- 需要leader selection 。违背了区块链的分布式本质,以及很难选出“correct” leader.
- 需要复杂的技术来规避不可能的结果。
- 昂贵的公钥加密技术来认证身份。
【一些联盟链系统】
- 瑞波币(Ripple)
- R3 constortium(金融机构联盟)
- 红蝮蛇区块链( The Red Belly blockchain)。使用DBFT (民主-实用拜占庭容错算法)解决了区块链拜占庭共识问题。Red Belly区块链实现了快速结算(通常在3秒内),因为它不需要任何工作量证明。上述两个系统的联盟通常是静态的,但是Red Belly区块链提供了一个动态的联盟:当前联盟的成员决定联盟的变更,一旦决定,新联盟将负责参与进一步的共识。通过这种模型,区块链的任何参与者最终都可以成为负责决策的共识参与者。
From blockchain consensus back to Byzantine consensus相关推荐
- FastBFT共识协议:Scalable Byzantine Consensus via Hardware-assisted Secret Sharing
文章目录 摘要 1.介绍(INTRODUCTION) 2.基础(PRELIMINARIES) 2.1状态机复制(State Machine Replication (SMR)) 2.2 Practic ...
- 【论文阅读】Gosig: A Scalable and High-Performance Byzantine Consensus for Consortium Blockchains
文章目录 标题 摘要 1 介绍 2 相关工作 3 综述 3.1 系统模型和假设 3.2 Gosig 协议概述 4 Gosig协议设计 4.1 消息和状态定义 4.2 第一阶段:区块提案 4.3 第二阶 ...
- 【论文阅读】DispersedLedger: High-Throughput Byzantine Consensus on Variable Bandwidth Networks
文章目录 摘要 1 简介 2 背景及相关工作 2.1 BFT 问题 2.2 可验证信息分散 2.3 异步 2.4 安全模型 3 A AVID-M:一种高效的 VID 协议 3.1 问题陈述 3.2 A ...
- 面向征信的区块链模式设计与应用研究
作者:郭树行,宋子琦 (中央财经大学信息学院,北京 102206) 摘 要:根据目前我国征信体系现状,结合传统征信体系结构所产生的问题,从监管层面提出基于区块链技 术的征信行业体系结构和 2 种数据交 ...
- 探讨BFT的关键细节及Libra的Consensus组件
探讨BFT的关键细节及Libra的Consensus组件 为什么需要Consensus? 主流的共识 BFT如何达成共识 BFT的安全性与活性 能容忍的拜占庭节点数 同步与异步 PBFT和两阶段确认 ...
- In Search of an Understandable Consensus Algorithm(Extended Version)
In Search of an Understandable Consensus Algorithm(Extended Version) 摘要:Raft是一种用于管理日志复制的一致性算法.它能和Pax ...
- 《In Search of an Understandable Consensus Algorithm》翻译
Abstract Raft是一种用于管理replicated log的consensus algorithm.它能和Paxos产生同样的结果,有着和Paxos同样的性能,但是结构却不同于Paxos:它 ...
- Joint Consensus两阶段成员变更的单步实现
简介: Raft提出的两阶段成员变更Joint Consensus是业界主流的成员变更方法,极大的推动了成员变更的工程应用.但Joint Consensus成员变更采用两阶段,一次变更需要提议两条日志 ...
- In Search of an Understandable Consensus Algorithm(寻找可理解的共识算法)
原文见 Raft Consensus Protocol 题目:In Search of an Understandable Consensus Algorithm 作者:Diego Ongaro an ...
最新文章
- [javaweb] servlet介绍与servlet的继承关系 和 service 方法 (一)
- Vue 动态路由的实现以及 Springsecurity 按钮级别的权限控制
- PPT怎么在线转视频?
- 听说容器正在吃掉整个软件世界?
- php private方法,php如何调用private方法
- 在linux中 要删除abc目录,操作系统原理与应用(linux)A卷
- linuxSAMBA共享
- nginx nodejs环境配置_在Linux系统配置Nodejs环境的最简单步骤,部署多个thinkjs(nodejs)项目...
- 14.jQuery常用方法
- 【Matlab】 读取文件各种方法
- vc2005编译出来的程序实现绿色版,即无须安装运行库
- 虚拟机克隆之后的IP修改问题
- oracle truncate可以恢复吗,恢复truncate表
- 解决python爬虫出现的521问题
- java 时区 edt_JAVA TimeZone发行EDT对EST
- Rebuttal得来的经验
- 第二语言教学的5c标准是哪5c,【英语教学论文】5C标准对大学英语教育的启示探讨(共3451字)...
- 打印圆周率指定位数之python
- 解析飞凌嵌入式i.MX8MM在智慧医疗麻醉系统中的应用方案
- 10.区块链系列之hardhat部署抵押赎回Fund合约