EOS代码分析1 理解EOS共识机制BFT-DPoS

EOS 最新的白皮书中已经将共识机制从 DPoS 升级为了 BFT-DPoS(Byzantine Fault Tolerance - Deligated Proof of Stake,带有拜占庭容错的委托股权证明)。

传统 DPoS
EOS 项目刚刚发布的时候的共识机制是 DPoS(Deligated Proof of Stake,委托股权证明),类似于 Bitshares 和 Steem,这种共识机制采用随机的见证人出块顺序,出块速度为 3 秒,交易不可逆需要45秒。为什么需要 45 秒呢?因为 DPoS 下,见证人生产一个新区块,才表示他对之前的整条区块链进行了确认,表明这个见证人认可目前的整条链。而一个交易要达到不可逆状态,需要 2/3 以上的见证人确认,在 EOS 里就是 14 个见证人。我们假设一个交易被包含在 1000 号区块中,需要其他13个见证人轮流出块至 1013 号区块,这样才能“收集”到14个见证人对此交易的确认(包括生产1000区块的见证人)。2/3 以上的见证人确认的交易,就是不可逆的交易了,这就是 45 秒确认时间的由来。

BFT的全称是Byzantine fault tolerance,即拜占庭容错。是解决拜占庭将军问题中,当存在叛徒时,叛徒用尽了各种手段来破坏时,将军们仍然能够达成达成共识。所以叫拜占庭容错,容错的意思就是容纳节点出现错误(或者叛徒),网络仍然能达成一致的行动,正常运作。
在新的机制下,每个见证人出块时依然全网广播,其他见证人收到新区块后,立即对此区块进行验证,并将验证签名完成的区块立即返回出块见证人,不需等待其他见证人自己出块时再确认。从当前的出块见证人看来,他生产了一个区块,并全网广播,然后陆续收到了其他见证人对此区块的确认,在收到 2/3 见证人确认的瞬间,区块(包括其中的交易)就不可逆了。交易确认时间大大缩短,从 45 秒缩短至 3 秒左右(主要为等待生产区块的时间)。这种机制可以称为初级版的 BFT-DPoS 共识机制。

BFT-DPoS
为了挖掘 EOS 系统的性能,Daniel Larimer 在以上基础上又进行了修改。首先,他将出块速度由 3 秒 缩短至 0.5 秒,理论上这样可以极大提升系统性能,但带来了网络延迟问题:0.5 秒的确认时间会导致下一个出块者还没有收到上一个出块者的区块,就该生产下一个区块了,那么下一个出块者会忽略上一个区块,导致区块链分叉(相同区块高度有两个区块)。比如:中国见证人后面可能就是美国见证人,中美网络延迟有时高达 300ms,很有可能到时美国见证人没有收到中国见证人的区块时,就该出块了,那么中国见证人的区块就会被略过。
为解决这个问题,Daniel Larimer 将原先的随机出块顺序改为由见证人商议后确定的出块顺序,这样网络连接延迟较低的见证人之间就可以相邻出块。比如:日本的见证人后面是中国的见证人,再后面是俄罗斯的见证人,再后面是英国的见证人,再后面是美国的见证人。这样可以大大降低见证人之间的网络延迟。使得 0.5 秒的出块速度有了理论上的可能。
为了保证万无一失,不让任何一个见证人因为网络延迟的意外而被跳过,Daniel Larimer 让每个见证人连续生产 6 个区块,也就是每个见证人还是负责 3 秒的区块生产,但是由最初的只生产 1 个变成生产 6 个。最恶劣的情况下,6 个区块中,最后一个或两个有可能因为网络延迟或其他意外被下一个见证人略过,但 6 个区块中的前几个会有足够的时间传递给下一个见证人。
再来讨论 BFT-DPoS 的交易确认时间问题:每个区块生产后立即进行全网广播,区块生产者一边等待 0.5 秒生产下一个区块,同时会接收其他见证人对于上一个区块的确认结果。新区块的生产和旧区块确认的接收同时进行。大部分的情况下,交易会在 1 秒之内确认(不可逆)。这其中包括了 0.5 秒的区块生产,和要求其他见证人确认的时间。

原文地址:https://blog.51cto.com/13878196/2378714

时间: 2024-11-03 02:42:46

EOS代码分析1 理解EOS共识机制BFT-DPoS的相关文章

EOS代码分析3 EOS存储机制的IPFS分布式文件系统

EOS使用IPFS分布式文件系统作为底层存储.IPFS是一种内容可寻址.点对点.通过http协议传输的分布式文件系统.IPFS采用content-addressable寻址技术,即通过文件内容进行检索而不是通过文件的网络地址.简单来说,就是对文件内容进行hash运算,将hash值作为文件名保存在本地数据库中,所以,只要文件内容不变,则文件名也保持不变.运行IPFS的节点,既是客户端又是服务器.客户端通过发送文件名到服务器,请求下载文件,服务器会根据文件名到数据库中查找对应的文件,查找成功后将文件

EOS代码分析5 接收网络信息

网络部分:Main(){app().set_version(eosio::nodeos::config::version);app().register_plugin<history_plugin>(); //通过register_plugin()函数将插件注册到application的plugins插件集合中,plugins是一个map容器auto root = fc::app_path(); //设定数据和配置路径app().set_default_data_dir(root / &quo

EOS代码分析6 P2P主动握手过程

主动链接对端connect( seed_node ); 链接peer节点if (start_session( c )) { c->send_handshake (); //发送握手协议 }c->send_handshake (); //初始化结构体,发送握手协议,协议最后要enqueuehandshake_initializer::populatequeue_write(); 发送缓冲过去[发送缓冲后,如何把缓冲发送过去?] 主动发送的握手数据内容voidhandshake_initializ

【许晓笛】详解 EOS 的新共识机制 BFT-DPoS

EOS 最新的白皮书中已经将共识机制从 DPoS 升级为了 BFT-DPoS(Byzantine Fault Tolerance - Deligated Proof of Stake,带有拜占庭容错的委托股权证明),本篇文章将详解新共识机制的原理. 传统 DPoS EOS 项目刚刚发布的时候的共识机制是 DPoS(Deligated Proof of Stake,委托股权证明),类似于 Bitshares 和 Steem,这种共识机制采用随机的见证人出块顺序,出块速度为 3 秒,交易不可逆需要4

第14讲 | 深入区块链技术(六):DPoS共识机制

上一篇文章里,我们讲解了PoS共识机制,这一篇我们来分享PoS的一个扩展机制,这个机制在业界也非常的流行,它叫做DPoS共识机制.DPoS全称是Delegated Proof of Stake,中文翻译过来是代理权益证明. 从BM开始聊起的故事 我们聊DPoS时,为什么要从BM聊起呢, 其实,这和聊比特币绕不开中本聪一样,DPoS是BM一手创造的.DPoS不是独立提出的共识算法,而是直接被BM应用到比特股项目中,在稳定运行了3年多后,又接着被BM构造成可复用的区块链工具箱:石墨烯. 虽然应用得很

恶意代码分析实战

恶意代码分析实战(最权威的恶意代码分析指南,理论实践分析并重,业内人手一册的宝典) [美]Michael Sikorski(迈克尔.斯科尔斯基), Andrew Honig(安德鲁.哈尼克)著   <恶意代码分析实战>是一本内容全面的恶意代码分析技术指南,其内容兼顾理论,重在实践,从不同方面为读者讲解恶意代码分析的实用技术方法. <恶意代码分析实战>分为21章,覆盖恶意代码行为.恶意代码静态分析方法.恶意代码动态分析方法.恶意代码对抗与反对抗方法等,并包含了 shellcode分析

【许晓笛】重新理解EOS的系统架构

从区块链三要素的角度 区块链系统中,去中心化程度与效率之间天然地存在矛盾关系.如果区块链智能合约系统想追求类似比特币的去中心化程度,理论上效率就会大打折扣.现实也是这样的:比特币每秒钟只能处理7笔左右的交易,每一笔交易要用至少30分钟才能确认,这种效率和速度是远远不如银行转账的.作为一个全球资产交易平台,比特币这样的效率或许可以接受,但对于智能合约平台这样的效率是远远不够的.因为在智能合约中,每一个动作都可以看成是一笔交易,例如五子棋游戏合约中,每下一步棋就是一个交易,用户是无法等待半个小时才能

Linux -- 内存控制之oom killer机制及代码分析

近期,线上一些内存占用比較敏感的应用.在訪问峰值的时候,偶尔会被kill掉,导致服务重新启动.发现是Linux的out-of-memory kiiler的机制触发的. http://linux-mm.org/OOM_Killer oom kiiler会在内存紧张的时候,会依次kill内存占用较高的进程,发送Signal 15(SIGTERM).并在/var/log/message中进行记录.里面会记录一些如pid,process name.cpu mask,trace等信息,通过监控能够发现类似

区块链共识机制的演进

分布式系统的基本概念 FLP不可能原理和CAP原理 FLP 不可能原理(FLP impossibility):在网络可靠,存在节点失效(即便只有一个)的最小化异步模型系统中,不存在一个可以解决一致性问题的确定性算法.1985年 FLP 原理实际上说明对于允许节点失效情况下,纯粹异步系统无法确保一致性在有限时间内完成. 科学告诉你什么是不可能的:工程则告诉你,付出一些代价,我可以把它变成可能. CAP 原理最早由 Eric Brewer 在 2000 年,ACM 组织的一个研讨会上提出猜想,后来