六、区块链主流共识算法浅析

转自:http://www.cocoachina.com/cms/wap.php?action=article&id=22240。

一、概述:

1.工作量证明(Proof of Work):
  通过所有节点的工作量竞争来达成一致。竞争的是运算力。

2.权益证明(Proof of Stake):
  通过节点拥有代币数量的多少和时间,确定下一区块的创造者。竞争的是拥有代币的数量和时间。

3.委任权益证明(DPOS):
  通过一定算法选取固定数量的代表投票来达成一致。如果某代表不能履行投票职责,会被除名,重新选择代表加入。

4.实用拜占庭容错共识(PBFT):
  PBFT是一种基于严格数学证明的算法,需要经过三个阶段的信息交互和局部共识来达成最终的一致输出。

二、工作量证明(Proof of Work)

区块链共识算法中最常见的是比特币的工作量证明机制,它主要有两个功能:一是保证区块链的下一区块是唯一正确的块,二是防止强大的敌手干扰区块链系统从而导致区块链分叉。

工作量证明中,矿工通过竞争解决密码学难题来完成下一个块的增加和区块链的扩展,如图1所示为比特币工作量证明的简图;参与挖矿的矿工竞争将前一区块的hash与一个随机的比特串一起来计算出一个hash值,若输出的hash值满足前若干比特为0,即为解出了该难题。第一个解出难题的人获得扩展一个块的机会,并且能够获得一定量新挖出的比特币以及一小笔交易费作为其工作量的奖励。

尽管比特币的工作量证明机制是个非常杰出的共识设计,但并不是完美的。最常见的对工作量证明的质疑有两点:一是消耗算力巨大,不适合大规模系统,并且交易的确认时间需要10-16分钟,不能满足实时性需求;二是大多数挖矿活动集中在电力成本较低的区域,形成了局部中心化的趋势。

比特币的创造者Satoshi Nakamoto让人们初步认识到区块链改变未来世界的巨大潜力,但落实到具体应用,仍需要进一步探索更快速的、更加去中心化以及资源效率更高的共识算法。为此,许多互联网、计算机科学、金融、工业等行业的学者和业界人士进行了不断的探索,并提出了若干代替性的区块链共识方案,其中最有影响力的是权益证明(Proof of Stake)共识算法。

三、权益证明(Proof of Stake)

权益证明共识是代替工作量证明的共识机制中最完善和受到最多关注的,其共识的达成不需要参与者投入昂贵的计算机设备来参与挖矿竞争。相对于以比特币为代表的工作量证明共识系统中的矿工而言,基于权益证明共识的区块链系统中,参与者的角色是验证者Validator,他们只需要投资系统的代币并在特定时间内验证自己是否为下一区块创造者,即可完成下一区块的创建。如图2所示为权益证明的简要示意图。下一区块创造者是以某种确定的方式来选择,被选中的验证者将合适的交易打包成块并发布到区块链上。验证者被选中为下一区块创造者的概率与其所拥有的系统中代币的数量成正比例,简单来说即拥有300个代币的验证者被选中为下一区块创造者的概率是即拥有100个代币验证者的3倍。

由于权益证明中创造区块不需要算力资源等高成本,区块创造者不会获得区块奖励,但可以获得一定数额的交易打包费用。用权益证明共识产生区块和扩展区块链的方式也比比特币中用工作量证明的共识效率提高上千倍,并且大大节约了资源。

权益证明共识中一旦验证者创建了一个块,该块也需要提交到区块链上。不同的权益证明系统对提交过程的处理方式不同。

一个典型的例子是Tendermint,其系统中的每个节点都必须在每一个块上签名(在此过程中的角色称为“签名者”),直至达成了大多数节点对区块验证和记录到链上的共识;在其他一些系统中,选择一组随机的节点进行签名即可达成共识。

权益证明有效率高、节约资源的优点,但同时也面临着一些潜在的现实风险,业内研究者通常将其表述为nothing-at-stake问题,意即区块创造者和区块验证者完成各自的工作所投入的成本都极低,因而违背系统协议作恶的损失也很小。基于理性人的自利假设,参与者难免会出现做恶的情况,例如区块创造者同时创造2个块并收取两笔交易费,或者签名者同时签名2个块以获得2笔工作报酬。这些都与系统协议中同一时间段只能产生一个合法的区块且签名者不可对不合法的区块签名的规范相违背。

在新兴的“加密经济学”领域,区块链工程师们正在探索解决这些问题的方法。其中一个解决方案是要求验证者将其拥有的系统代币锁定在一种虚拟保险库中。如果验证者试图对系统进行双重签名或同时产生多个块进行分叉,那么这些代币就会被全部或部分罚没。类似的改进机制也在不同的采用权益证明的区块链系统被提出并进行了许多实践。

Peercoin是第一个将权益证明实现的代币,其次是blackcoin和NXT。此外,以太坊最早依赖于工作量证明共识,但正计划在2018年初迁移到权益证明,提出Casper试图解决工作量证明和权益证明中的问题。Decred采用的是工作量证明和权益证明的混合共识方案。

四、委任权益证明DPOS

DPOS是权益共识的一种改进版本,共识过程不再需要所有参与节点的大多数通过,而是委托部分代表来进行,这样可以进一步提高共识效率,也能较好地处理系统节点不在线的问题。在比特股(Bitshare)系统中采用的DPOS共识的原理是让每一个持有比特股的人进行投票,由此产生101位代表, 他们彼此的权利完全平等,可以将其理解为101个超级节点或者矿池。

从某种角度来看,DPOS与议会制度或人民代表大会制度有相似之处。如果代表不能履行他们的职责,例如当轮到他们产生区块时没能按时生成,他们会被除名,继而网络会选出新的超级节点来将其取代。采用DPOS共识的系统通常都会采用经济方面的奖励和惩罚机制来达成更稳定的共识。

五、实用拜占庭容错共识PBFT

PBFT是一种基于严格数学证明的算法,需要经过三个阶段的信息交互和局部共识来达成最终的一致输出。可以证明,系统中只要有三分之二以上比例的正常节点,就能保证最终一定可以输出一致的共识结果,尽管达成共识的时间不确定。

实用拜占庭容错协议的缺点在于不适用于大规模的节点共识,因为随着节点规模的增大,达成共识需要的时间大大增加,不符合效率需求。许多相关研究人员在探讨改进拜占庭协议,以解决不同应用场景下的效率问题。

六、总结

共识算法的性能直接影响着分布式系统的性能,例如安全性、鲁棒性、共识成本和效率等。如何在兼顾安全性和鲁棒性的基础上提高效率是一个需要持续讨论和研究的重点。目前关于区块链共识的各种研究也在根据具体应用场景做出多方面的改进,除了技术方案的改进之外,还需要结合经济和社会等因素寻找更加有针对性、更加完善的解决方案。

总的来说,对于区块链共识方案的研究为分布式系统中的一致性问题提供了较好的解决方案,目前已经有一些算法能较好地解决分布式系统中的共识等问题,在EUROCRYPT,ACM, Cryptology ePrint Archive等高水平会议、刊物上也有高质量的文章发表,对于上述问题进行了更深刻和前瞻性的探讨,但该领域仍然由许多问题有待解决,仍有很大的研究价值和发展空间。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/499844.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

七、区块链如何运用merkle tree验证交易真实性

转载自:https://www.tangshuang.net/4117.html 本文假设你已经知道区块链中merkle tree的原理,现在搞明白具体怎么来实现交易真实性验证。 Merkle Tree 这个小节简述一下merkle的原理。简单说,merkle tree就是一个hash二叉树,父…

java基础 --- Arrays.asList():返回指定数组支持的固定大小列表

Arrays.asList():返回指定数组支持的固定大小列表 首先看下这个方法的源码注释,注意第一句,Returns a fixed-size list backed by the specified array., 意思就是:返回指定数组支持的固定大小列表 所以:…

Notepad++中的UTF-8无BOM格式编码

Notepad中,关于utf-8的编码格式,有两种:以UTF-8无BOM格式编码和以UTF-8格式编码。 很容易给人一种错觉,第一反应会选择以UTF-8格式编码,感觉这种就是平时所说的UTF-8,然而这种编码是默认带BOM的&#xff0…

Java 线程状态---WAITING(部分转载)

看到一篇关于写线程waiting状态的文章,感觉很生动有趣,转过来保存下。 总结: waiting这个状态,就是等待,明确了等待,就不会抢资源了。 一个线程A在拿到锁但不满足执行条件的时候,需要另一个线…

服务端高并发分布式架构演进之路(转载,图画的好)

这个文章基本上从单机版到最终版,经历了加缓存,加机器,高可用,分布式,最后到云等过程,其实我一直想总结一套类似的东西,没想到有人已经先弄出来了,那就不重复造轮子了,而…

限流算法(漏桶算法、令牌桶算法)对比

限流算法(漏桶算法、令牌桶算法) 漏桶算法: 有个桶,比如最大能进2个单位的水(请求),桶底有个洞,每个单位的水都会在桶里待3秒后漏下去。 那么这个桶就可以同时处理2个单位的水。 如…

mongodb 索引详解

使用springboot连接mongodb的时候,涉及到索引的使用 举例: Document(collection"book") //注释的是复合索引 //CompoundIndexes( // { // CompoundIndex(name "复合索引名字",def "{字段01:1,字段02:…

mongodb数据库,批量插入性能测试记录

spring boot 框架下,操作mongodb数据库 maven:spring-data-mongodb:2.1.3.RELEASE mongo数据库用的是本地的mongo,所以环境不一样,可能结果不一样。但趋势应该是一样的。 测试保证每次批量插入时,库里的数据量都是一…

[转载] --- 数据库基本知识

里面的很多点,我之前都总结过,但是感觉这篇把这些都连起来了,总结的挺好,转载保存一下 【从入门到入土】令人脱发的数据库底层设计前言 说到数据库这个词,我只能用爱恨交加这个词来形容它。两年前在自己还单纯懵懂的时…

spring-boot发送邮件失败 AuthenticationFailedException: 535 Authentication Failed

发送邮件失败,平时一直是好的,突然有天开始失败了,最后是发现邮箱密码失效了。。。 有的邮箱,需要定期更改密码。

互联网广告行业(01)------ 初识了解DSP、SSP、ADX

最近有幸接触到公司的一个实时竞价系统,也算是公司的核心系统之一了,增加了很多新的知识,可能有点乱,先总结一波: 广告行业,先介绍概念 广告主:需要打广告的站点,一般就是卖东西的…

互联网广告行业(02)------OpenRTB(实时竞价)规范解读

RTB:(Real Time Bidding实时竞价),RTB是一种广告交易的方式 OpenRTB:简单理解就是一个行业规范,是一个为了促进RTB方式广告的标准,有对应的api文档,大家都按照这个规范去传参数,那么发送方和接收…

[go]---从java到go(01)---基础与入门上手

为什么用go,就是为了快速响应并且高并发。 一样的逻辑,用java也能实现,但用go可能就比java快点。 如果你很熟练java了,那么学习go就会很快。 go的社区环境相比java没那么大,但一般问题都足够了。 go是谷歌出品&#xf…

[数据库] --- clickhouse

clickhouse是一个列式数据库(系统)。 官方文档 官网比较全,但也可以说比较杂,下面就是我个人的一些总结,以及在实际工作中的应用场景。 1.clickhouse适用场景 clickhouse主要适合那种大量数据做分析的场景。 一般数据…

消息队列(5):RocketMQ

介绍 RocketMQ是一款成熟的分布式消息中间件。 由阿里2012年开源,2017年成为Apache顶级项目。 源码是java写的。 高性能,低延迟,高可靠。历经多次双十一大促,整体很稳定。 RocketMQ对比其他mq的优势 对比kafka和Rabbitmq&#…

[错误记录] --- rocketmq批量消费设置参数的问题

rocketmq想支持批量消费,于是便设置以下参数: consumer.setConsumeMessageBatchMaxSize(1000);这样是正确的,但由于业务要求,还想再设置大点,于是设置成这样: consumer.setConsumeMessageBatchMaxSize(10…

阿波罗配置中心(apollo)的个人看法

阿波罗应该是近几年比较火的一个分布式配置中心了,说说我个人的理解,希望对一些人有用吧。 首先从使用者的角度想 我们怎么用配置中心的? 1.得有个页面,能有权限管理,能有创建配置key-value。 在阿波罗中&#xff…

消息队列(4):Kafka

介绍 kafka是一个支持分布式的消息系统,基于发布/订阅模式。 kafka由LinkedIn公司开发,2010年成为Apache顶级项目。 源码是由java写的。 基本概念 1、Broker kafka集群中的每台机器,都叫一个broker. 2、Topic(主题&#xff0…

clickhouse的ReplacingMergeTree引擎实战

学习ReplacingMergeTree引擎,首先你得了解clickhouse的MergeTree引擎,因为ReplacingMergeTree引擎是MergeTree引擎的一个扩展版引擎,他拥有和MergeTree一样的功能,同时新增了一个删除相同主键数据的功能。 我们知道,cl…

clickhouse 分片

我们知道mysql数据库如果想做分片,需要使用第三方组件,这是因为mysql在设计之初就没有太多考虑分布式等问题。而clickhouse作为新生代性能之王,分片也是必须的功能。基本上从2015年之后的各种数据库也罢,框架也罢,都开…