亲爱的好朋友们:上期小C吐了一下 IOTA。说实话,刚开始小C还有些忐忑,毕竟是小C出道的第一篇文章,文章内容也可能会引发一些激烈的辩论。结果,有很是多的朋友给了我点赞关注加鸡腿,这让小C很是受宠若惊。感谢你们对小C的支持和关注,小C必定会更加努力地为你们写出更多更好的文章,不辜负你们对小C的信任!今天小C又新鲜出炉一篇新的文章——想跟你们一块儿分享一下 Hashgraph 这个项目。
这个名为 Hashgraph 的分布式帐本于 2016 年横空出世,稍晚于上次讲过的“第一个使用了 DAG 技术”的公链项目 IOTA——若是 DAG (Directed Acyclic Graph,有向无环图)也能够被称为一种“技术”的话。Hashgraph 项目团队宣称:“这不是区块链,这是市场上第一个(甚至惟一一个)‘银行级’的共识技术。” ¹ 江湖传闻 Hashgraph 能够拳打比特币,脚踢以太坊,靠的就是不分片便可高达 50 万 tps 的硬实力 ² ,惟一的限制只有网速和想象力……顺便说一下,小 C 据说18年天猫双11的交易量峰值是 49.1万笔/秒,17年时候才 25.6 万笔/秒。html
2: https://www.hedera.com/whitepaper安全
随手放狗搜一下 Hashgraph 就能够发现,不管是在 Wikipedia 仍是在其余各类媒体上,这个项目的口气都大得吓人: “How Hedera Hashgraph is building a fast and secure blockchain alternative.”(Hashgraph 如何建造一个快速且安全的区块链替代者)这样的说法,已经算是很是谦虚的了,其余的还有如下这些:微信
简直一个项目要单挑全部区块链了!开头说的“拳打比特币,脚踢以太坊”已经算是很是谦虚的口号了。不过仔细研究之后,小 C 发现 Hashgraph 项目团队确实没有骗我——Hashgraph 真的是一个“银行级”的公用帐本,一个只有银行级用户才用得起的帐本。网络
Hashgraph是怎么作的?dom
小 C 在这里先来简单介绍一下 Hashgraph 的共识算法,对这部分比较熟悉或者不感兴趣的观众能够直接跳到下一节。异步
与 IOTA 所用的 Tangle 帐本不一样,Hashgraph 用了一种更规整的图结构“哈希图”去存储包含交易的区块(每一个区块在 Hashgraph 中记为一个“事件”(event)),并经过一个 aBFT (Asynchronous Byzantine Fault Tolerant, 异步的拜占庭容错,指系统在不超过三分之一的节点被攻击者控制,且诚实的节点之间通讯延迟能够被任意延长的状况下仍能够保证安全性)的共识算法来保证全部人对整个帐本达成共识。分布式
简单来讲,Hashgraph 共识算法的基本逻辑就是:假设大多数参与者都是好人,那么当交易被足够多数人(好比三分之二以上的比例)见证之后,就能够确认这些交易的顺序以及它们是否有效了。只要系统里大部分人都是诚实的,那么多数人见证过的历史就能够沉淀为没法改变的共识。post
Hashgraph 共识算法采用了一种“见证即投票”的方式对交易历史排序。当一个参与者 Alice 看到有新鲜事发生的时候,好比一笔新的交易 T,就把这些新鲜事打包到一个区块 B 里;除了亲眼所见的之外,Alice 构造的区块还须要引用两个更早的区块,其中一个是 Alice 本身生成的前一个区块,另外一个是从其余参与者那里收到的最新的区块。而后再给 B 加上时间戳和 Alice 的签名,就能够把区块 B 悄悄地告诉另外一个随机选择的参与者 Bob 了。未来 Bob 就能够再经过引用区块 B 的方式,做为见证者把 “Alice 告诉我某时某刻发生了一笔交易 T” 的信息继续传播给其余人。因而,Alice 发起的这笔交易 T 就能以八卦的形式在参与者之间飞快地传播,只须要大约 log(N) 次就能够传遍 N 个参与者。果真,八(yao)卦(yan)传播的速度就是比正经的广播要快得多呢~性能
Hashgraph 将全部区块按照他们之间的哈希引用关系组织成 DAG ,称为一个“哈希图”。哈希图不一样于通常的有向无环图, 它有着很是鲜明的结构特征,即每一个参与者都有一条链,同时链上的每一个区块都引用一个别的链的区块。哈希图实际上描述了“事件”在“八卦网络”(Gossip Network)中传播的路径。经过观察本地存储的哈希图咱们不只能够判断一个事件是否已经被大多数参与者见证,还能够肯定每一个参与者见证不一样的事件的前后顺序。
Hashgraph 相对于传统 BFT 算法最大的优点,就在于 N 个参与者只须要每人发送大约 log(N) 条消息就能够完成一轮投票。要知道,在普通的 BFT 算法里,每一个参与者但是要发 N-1 条点对点的消息才能作完成一轮投票的。听上去是否是很厉害?简直 too good to be true!
为何 Hashgraph 能够作得这么好呢?其实有一个比较微妙的小问题,只是由于 Hashgraph 相关的文档写到这里都是一笔带过的,因此小 C 至今没有看明白:传播八卦的时候,一条消息到底有多长?
按照 Baird 2016年的 Hashgraph 论文的说法(“… Alice will choose another member at random, such as Bob, and then Alice will tell Bob all of the information she knows so far”)彷佛是要 Alice 把全部知道的信息都告诉 Bob。因此,Alice 发给 Bob 的信息可能不止是一个区块 B,还包括这个区块 B 直接间接引用的的全部其余区块——难道要把整个帐本的历史都放在一条消息里发出去?即便 Alice 很是聪明,记得她上次都告诉了 Bob 哪些八卦,每次只须要同步新八卦,那么每条消息的长度也依然会达到参与者人数的线性量级。如此看来, Hashgraph 能够少发不少条消息就没那么神奇了。由于虽然条数少了,可是新包装的一条消息的内容可能就长得能够绕地球1圈~
最后算下来,Hashgraph 彷佛也就是一个没有比传统的 BFT 算法节约什么的 BFT 算法。
接下来,小 C 来给你们算一下 Hashgraph 的几十万 tps 究竟是什么概念。
若是按照 Hashgraph 的测试网数据 25万 tps,每笔交易按 250 字节计算, 仅同步交易就须要 250000*250=62500000 B/s=62.5 MB/s 带宽。若是按照官网白皮书所说的 50万 tps,则须要 125MB/s 带宽。注意,这尚未计算除了交易自己之外的任何开销。因此在 5G 普及以前,普通用户下载速度都赶不上 Hashgraph 增加的速度。
姑且先不讨论带宽,那么什么样的机器才能处理每秒数十万笔交易呢?以如今典型的机器配置,单核 CPU 每秒钟也就能验证几千笔交易的签名,强如 EOS 的超级节点在峰值时刻处理的交易数量也不过每秒四千笔左右。而 Hashgraph 除了处理帐本上的每笔交易之外还要维护八卦图和虚拟投票,这又是一笔不小的开销。
综上所述,只有银行级或者企业级的硬件才配得上 Hashgraph 了。
Hashgraph 超高的安全性要求三分之二以上的参与者见证才能确认一笔交易,这样少数坏人再也没法修改公共帐本。可是另外一方面,这个机制也有很是严重的缺点——共识参与者的活跃性问题。
Hashgraph 共识参与者们必须很是活跃,不然就会由于见证人数不够而没法达成任何共识。在现实中任何一个去中心化的系统中,普通用户通常都是长期不在线的,能长期活跃在线的只有:1)银行和交易所;2)庄家;3)矿工(Hashgraph 没有 PoW,没有矿工) 以上都是。因此,一个由银行级和企业级用户维护共识的公共帐本,当得起一句“银行级”的安全性。
小 C 建议 Hashgraph 项目也不要总拿着“银行级”联盟帐本的性能去找比特币和以太坊等公链碰瓷,都不是一个赛道上有什么比如的。还不如好好跟别的基于 pBFT(实用拜占庭容错)的公共帐本比比孰优孰劣更有意义。
若是 Hashgraph 实在眼红公链这块蛋糕,也应该严谨地分析 Hashgraph 在公链环境下的安全性,而后用同口径的性能数据去跟别人比较,不然再怎么比也只是鸡同鸭讲罢了。原本嘛,若是 Hashgraph 只是作一枚安安静静的 BFT 帐本,不要出来喊打喊杀地要作颠覆区块链的“Blockchain killer”,咱们也不会想起来要拍它不是吗?就像裘千丈裘老前辈的职业规划若是是作一名魔术师或者杂技演员,那绝对是一位德艺双馨的老艺术家,也不会挨打对不对?
事实上,Hashgraph 项目也确实是按照联盟帐本搞的,他们组织了一个由 39 个组织和企业构成的委员会去维护和运行这个分布式的帐本。
至于开不起银行的普通用户嘛……我以为支付宝和微信都是不错的企业级帐本和 APP 平台。他们若是愿意把各地的机房拆分红不一样的公司分别运营甚至卖掉几个的话,应该也能达到不输 Hashgraph 的“去中心化”程度。
好了,这一期的内容就先到这里了!小伙伴们,若是大家看后感受到了欢乐,以为内容充实又有趣的话,记得多都支持我呀!动动手指点个赞,关注一下咱们公众号吧~
顺便推荐一下咱们的线下活动~在本期Conflux Meetup,咱们为你们邀请到了Conflux CTO伍鸣、Conflux研究总监杨光、Cobo钱包高级副总裁李尧来一块儿聊一聊《下一代公链和DApps生态前景》。
点击报名