EOS从入门到精通-设计背景与DPOS算法(文字稿)
大家好,非常感谢参加《EOS从入门到精通》系列课程,我是王巨。先跟大家汇报一下上周六试讲的情况,上周6的试讲已经有6000多小伙伴参与了试听,在此我非常感谢大家的信任。同时在试讲的过程中大家反馈比较多的问题有两个,一个是在讲课的过程中好像是在一字一句的读,第二个是每次发的语音时间都比较短。这个我解释一下,我确实是一字一句读的,为了保证课程的质量,我现在大概会花费一整天的时间来准备课程,同时我暂时不具备脱稿将整个课程讲清楚的能力,因此我都会将我要讲的内容只字不差的写成文字稿,然后再练习一遍,然后再在直播间中跟大家讲一遍,为了能清楚准确的表达我想要讲的内容,以我现在的能力大部分内容只能读文字稿,同时读太多中途出错的概率就会变大,我就只能缩短每次表达的时间了。后面我会尽最大努力来改善这种情况,同时在每节课之后几天内我会放出课程的文字稿供大家参考。
好的,我们开始我们的课程,从本节课开始,我们着重解读EOS的官方文档,今天解读白皮书的第一二两部分,区块链应用的要求和DPOS算法介绍。先简单说一下EOS的背景,我们知道EOS主要开发人员是Dan Larimer江湖人称Byte Master简称BM,在他开发EOS之前已经有两个成功的区块链项目了,一个是去中心化的交易所BTS,一个是去中心化的社交平台steamit,这两个去中心化应用都非常成功,提供了堪比中心化应用的用户体验。虽然这两个项目在成功后BM就退出了,但就我个人而言我是能理解BM为了自己的理想而放弃这两个项目的行为。EOS就是大概率能实现BM部分理想的项目。
我们顺着白皮书的思路看一下,一个区块链应用的需求 或者说 真实世界对区块链应用的要求,白皮书上说了6点,分别是:
支持大量用户
免费使用
方便的升级和Bug修复
低延时
时序性能
并发性能
支持大量用户大家都能理解,用户数量其实是一切应用的基础,对于一个应用如果不能支持大量用户,或同时使用的人多了网络就拥堵这在用户体验上就是没办法接受的。所以支持大量用户是一切DApp成功的前提。
免费使用,在上一讲我也说过了,是否跟用户收费是应用服务商决定的,不是基础平台决定的。这点btc和eth做得都不好。当然不将他们看成平台,而只是看成一个区块链应用,那么他们收费也没有问题。显然EOS是奔着平台的设计目标去的。
方便的升级和Bug修复,在讲为什么之前,我们先看看现有区块链升级和解决问题的方式:软分叉和硬分叉。软分叉在9月份之前比特币上体现比较多,比如说旷工支持软分叉,社区支持软分叉,软分叉就是在一段时间内新旧代码一起用,新旧代码产生的块都是相互认可的,只是新代码在某个旧代码不关心的数据结构中加了一个自己的标识,实现新的逻辑。
硬分叉现在越来越多了,比如说:比特币的各种儿子,对吧,这种硬分叉已经不是为了解决实际问题了,基本都是利益驱动了,这里我们不去讲。当然最著名的一次硬分叉还是要属eth,分叉的原因是由于合约漏洞,theDAO 项目众筹的eth被盗,后来eth社区为了挽回损失将区块进行了回滚和硬分叉。讲了这么多,大家发现了一个问题没有,不管是硬分叉还是软分叉,都有点像事后的补救措施,而事前没有约定好遇到问题了应该怎么解决。凡是软件都会有Bug,这是不可避免的,而方便的升级和Bug修复理念会很好的解决这个问题。平台本身应该具备这种鲁棒性以应对这种不可避免的Bug。
低延时、时序性能、并发性能在上一节课中已经大家讲过了,这里再稍微说一下:
延时是用户体验杀手,现在的App用户对延时的容忍度越来越低了,一旦延时高到用户没法接受的程度,那用户就会放弃这款软件。
再说一下时序性能,一些应用因为顺序依赖关系而不能使用并发算法实现。 比如交易所就需要足够的时序性能来处理很高的交易量,因此高时序性能对于平台来讲是必须的。这其实体现的是平台的纵向扩展能力。
并发性能:这个不多说了,这体现的是平台的横向扩展能力,平台能否支持大量的应用主要看平台的并发处理能力,而且应用之间相互之间不能存在性能依赖。
好了,区块链应用的需求我们就讲到这里,下面讲一下DPOS共识算法:
讲到共识算法就不能不谈一下拜占庭将军问题,相信来听EOS课程的同学大部分都是听过比特币课程的,一般比特币课程讲共识的时候都会讲拜占庭将军问题。我在这里简单描述一下拜占庭将军的问题,想象一下,在拜占庭时代有一个坚固的城邦,拜占庭,高墙之内有多到它的邻居无法想象的财富。它被其他10个城邦所环绕,这10个城邦也很富饶,但和拜占庭相比就微不足道了。它的十个邻居都觊觎拜占庭的财富,并希望侵略并占领它。
但是,拜占庭的防御非常强大。任何单一城邦的入侵行动都会失败,而入侵者的军队也会被歼灭,使得其自身容易遭到其他九个城邦的入侵和掠夺。这十个城邦之间也互相觊觎对方的财富并持续互相对抗着。而且,拜占庭的防御强大到,要十个邻居的一半以上同时进攻才能攻破它。
也就是说,如果六个或者更多的相邻国家一起进攻,他们就会成功占领拜占庭,并获得拜占庭的财富。然而,如果其中有一个或者更多背叛了其他人,答应一起入侵但在其他人进攻的时候又不干了,也就导致只有五支或者更少的军队在同时进攻,那么所有的进攻军队都会被歼灭,并随后被其他的(包括背叛他们的那(几)个)邻居所劫掠。这是一个由不互相信任的各方构成的网络,但他们又必须一起努力以完成共同的使命。城邦不能聚到一起开会(分布式),同时各个城邦间可以可以进行点对点通讯,大家可以想象一下,如果没有共识协议那么城邦间的通讯是否能正常进行?a说9点攻城,b不相信,说要10点开始最终所有的信息都变得不可信任、相互矛盾而完全没有用处。
上面简单的将问题说了一下,那比特币的网络是怎么解决在不互相信任的网络中达成共识的呢?比特币精妙的设计了一个工作量证明的机制,就是让每个节点在记账前完成大量的运算,然后再广播全网,全网节点收到后大家都认可该节点的记账。这就是POW共识算法的原理。
再说一下POS共识算法,该算法记账权不是使用工作量证明,消耗的不是计算资源,消耗的是POS网络内的一个叫币天的概念。币天是什么意思呢?大概等于 持有的币 乘以 在系统里面的未被使用的天数。币天越大得到记账权的概率也就越大,当然记完账之后你的币还在,未被使用的天数会被清零。以上是POS共识算法的基本原理。
那POW和POS共识的缺点是什么呢?POW的算法决定了性能不会高,同时需要浪费大量的能源,做一些hash运算,而这些运算本身是没有意义的。典型应用比特币和以太坊。同时现在挖矿已经出现了大矿池算力过大的风险。
POS相对于POW在性能上会有比较大的提高,当然提高也是相对的,对于一个应用平台来讲这是远远不够的。缺点主要是来做于系统内贫富差距会被拉大的问题。
我们再来看看DPOS算法的介绍,这部分会根据白皮书重点讲一下:
DPOS算法目前来看 是唯一能满足区块链之上 应用性能需求 的 去中心化共识算法。
在这种算法下,区块链上持有Token的人可以通过投票系统选择区块生产者,当然任何人也都可以选择参与区块生产,并有机会生产与总票数成正比的区块。 对于私有链,管理员可以使用Token来添加和删除IT人员。
DPOS协议一般规定每3秒产生一个区块,为什么是3秒,这可能是基于当时的性能需求的考虑认为3秒时间已经非常短了,Github上显示EOS的开发团队正在测试亚秒级的区块生产,将区块的生产效率进一步提升。目前EOS使用的还是3秒产生一个区块。
DPOS算法一般规定,区块生产者的个数为21个或101个,也可以是其他的数量。目前EOS使用的数量是21。由 21 名生产者轮流产生新的区块。
在一般情况下,一个 DPOS 区块链不会经历任何的分叉,因为被选举出来的区块生产者是通过合作而非竞争的方式来生产区块。 即便真的出现了分叉,共识也将自动的切换到最长的链上。
区块添加到一个区块链分叉的速率与公用同一共识的区块生产者比例是相关的。 换句话说,具有更多生产者的区块链分叉会比拥有较少生产的那一个条增长的速度更快。 而且,没有一个生产者会同时在两个分叉上同时生产区块。 如果一个区块生产者被抓到做这样的事儿,那么这个生产者将被投票投出。
交易确认
典型的DPOS区块链 100% 有区块生产者参与。一个交易从广播开始后平均 1.5 秒就可以 99.9% 被认为是确认了。为什么是1.5s而不是3s我这点也还没想明白。等我们提高篇开课时会将该问题讨论清楚。
在一些特殊情况下会有例外,比如,软件出现 bug,网络拥塞,或一个恶意的区块生产者制造了两个或更多的分叉。 为了确保一个交易绝对是不可逆的,一个节点可以选择等待 21 个区块生产者中的 15 个给出确认。一般情况这个过程平均需要 45 秒的时间。 默认情况下,所有的节点将认为当 21 个生产者中有 15 个给出确认后这一区块就是不可逆的了,并且不管长度如何都不会切换到没有这一区块的分叉。
在分叉开始的 9 秒内,一个节点就可以警告用户他们极可能正处于分叉中。 在连续丢失 2 个区块后,有 95% 的概率可以确认一个节点处于分叉中。 在连续丢失 3 个区块后就有 99% 的概率确认。
讲了这么多,DPOS共识的优点和缺点是什么呢?
主要优点就是超高性能,这是其他算法没办法匹敌的,仅这一点,再对应到EOS的设计目标,EOS在共识算法的选择上就不会有其他的选项。那为什么会有这么高的性能呢?我们可以看到在一个记账周期内参与记账的见证人是固定的,这就避免了找节点记账带来的时间损耗。从实际运行情况来看bts、steamit以及在公信宝都是落地项目,已经稳定运行非常长的时间了,证明该算法经得起时间的考验。
再说一下竞争对手经常被批评DPOS的中心化风险:
对比一下POW算法与POS算法,DPOS默认使用21个节点来产生区块,看起来比比特币和以太坊的成千上万个节点少太多了,从数量上看DPOS算法绝对有中心化的嫌疑,但是真实情况如何呢?POW算法的比特币算力前三的矿池占算力接近50%,POS算法会有拉大贫富差距的嫌疑,币会越来越想富人身上聚集。所以目前来看,POW和POS并没有解决趋向于中心化的问题。而DPOS算法从算法层面定义了一个分布范围,21个活跃节点,当然还有非常多的没有记账权的节点等待接班。只要节点作恶就会被投票出局,因此其设计上中心化的风险反而相对比较低。
好了今天的课程就到这里,总结一下今天讲了两方面的内容:区块链应用的需求以及共识算法简介。区块链应用需求分别是:支持大量用户、免费使用、方便的升级和Bug修复、低延时、时序性能、并发性能。共识算法简介介绍了:POW算法、POS算法、重点介绍了DPOS算法,介绍了这些算法的优点与缺点。
非常感谢大家的参与,现在大家可以就上面的话题提出问题,我会选一些能回答的问题跟大家共同讨论。谢谢大家。
作者:王巨
链接:https://www.jianshu.com/p/0bad616c48df
來源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
EOS从入门到精通-设计背景与DPOS算法(文字稿)相关推荐
- EOS从入门到精通(三)
大家好,非常感谢参加<EOS从入门到精通>系列课程,我是王巨,今天是EOS技术白皮书解读的第三讲.今天我们来解读EOS白皮书中的"应用程序的确定性并行"和"T ...
- EOS从入门到精通-账户体系(文字稿)
大家好,非常感谢参加<EOS从入门到精通>系列课程,我是王巨,今天是EOS技术白皮书解读的第二讲.今天的课程原本计划讲两部分内容,账户系统和并行执行.但是一天的备课下来,我发现账户系统的内 ...
- EOS从入门到精通(四)
大家好,非常感谢参加<EOS从入门到精通>系列课程,我是王巨,今天是EOS技术白皮书解读的第四讲.我们来解读EOS白皮书的最后几部分.今天的内容相对于上一节课会简单一些,主要讲EOS的治理 ...
- 《C++ 开发从入门到精通》——2.5 算法是程序的灵魂
本节书摘来自异步社区出版社<C++ 开发从入门到精通>一书中的第2章,第2.5节,作者: 王石磊 , 韩海玲,更多章节内容可以访问云栖社区"异步社区"公众号查看. 2. ...
- (Object detection)目标检测从入门到精通——第五部分YOLO 算法
你们已经学到对象检测算法的大部分组件了,在这个视频里,我们会把所有组件组装在一起构成YOLO对象检测算法. 我们先看看如何构造你的训练集,假设你要训练一个算法去检测三种对象,行人.汽车和摩托车,你还需 ...
- Python实战从入门到精通第五讲——数据结构与算法3之序列中出现最多的元素
怎么找到序列中出现次数最多的元素呢? collections.Counter类就是专门为这类问题设计,甚至有一个most_common直接给出答案 假设一个数字列表想找出哪个数字出现频率高 words ...
- Python实战从入门到精通第三讲——数据结构与算法1之解压序列赋值
1.解压序列赋值给多个变量 任何的序列可以通过一个简单的赋值语句解压并赋值给多个变量,唯一前提是变量数与序列元素相同 data = ['ACME',50,91.1,(2012,12,21)] name ...
- 惯性室内导航入门到精通(3)-计步算法
接上文,已经获得三轴加速度了,如何由三轴的加速度计算出步数呢.当手机移动时,手机三轴加速度也会变化,且这些变化中是有一定的规律的,通过规律就能写出相应的算法来解决.(具体可通过下载测试软件进行观察) ...
- 深度学习从入门到精通——图像分割之DeepLab系列算法
DeepLab系列算法 图像分割传统做法 解决方案 参数计算 图像金字塔 SPP-Layer 常用的多尺度提取方法 ASPP(atrous convolution SPP) deepLabv3+ 图像 ...
最新文章
- java sdcard path_更改 android 文件存放目录 getWritablePath() 为sdCard
- CactiEZ V10.1 中文版 Cacti中文解决方案+使用教程(1)
- 华南理工大学和浙大计算机学院,浙江大学和华南理工大学的办学实力比较
- 在服务器生成ssl认证
- QT乱码总结4.细谈本地编码
- vue-cli3使用svg图标的详细步骤
- java项目引入json配置,TS-28 配置tsconfig.json(3):工程引用
- C#使用SmtpClient发送邮件解决授权码配置问题
- 游戏筑基开发之结构体(数组、指针)、枚举、共用体、typdef(C语言)
- 记一次2048小游戏开发
- 小米蓝牙音箱驱动_2020年度智能音箱拆解报告汇总,涵盖27个品牌72款产品
- [c++] gdiplus绘制透明异型窗口
- rose双机热备mysql,实战:ROSE HA双机热备系统安装指南
- 50以内的质数顺口溜_100以内的质数顺口溜
- NetBeans ide操作流程及注意事项
- 第九届蓝桥杯(国赛)——阅兵方阵
- 视频物体检测(VID) FGFA:Flow-Guided Feature Aggregation for Video Object Detection
- Flooding、Gossiping、SPIN、DD路由、Rumor路由这五个协议的区别和联系
- GB2312(部分GBK)汉字编码表
- 粒子群算法python(含例程代码与详解)