亲爱的好朋友们：上期小C吐了一下 IOTA。说实话，刚开始小C还有些忐忑，毕竟是小C出道的第一篇文章，文章内容也可能会引起一些激烈的辩论。结果，有非常多的朋友给了我点赞关注加鸡腿，这让小C非常受宠若惊。感谢大家对小C的支持和关注，小C一定会更加努力地为大家写出更多更好的文章，不辜负大家对小C的信任！今天小C又新鲜出炉一篇新的文章——想跟大家一起分享一下 Hashgraph 这个项目。
Hashgraph 是什么？
这个名为 Hashgraph 的分布式账本于 2016 年横空出世，稍晚于上次讲过的“第一个使用了 DAG 技术”的公链项目 IOTA——如果 DAG （Directed Acyclic Graph，有向无环图）也可以被称为一种“技术”的话。Hashgraph 项目团队宣称：“这不是区块链，这是市场上第一个（甚至唯一一个）‘银行级’的共识技术。” ¹ 江湖传闻 Hashgraph 可以拳打比特币，脚踢以太坊，靠的就是不分片即可高达 50 万 tps 的硬实力 ² ，唯一的限制只有网速和想象力……顺便说一下，小 C 听说18年天猫双11的交易量峰值是 49.1万笔/秒，17年时候才 25.6 万笔/秒。
1：www.thestreet.com/story/14385…
-
“Hedera Hashgraph Thinks It Can One-Up Bitcoin And Ethereum With Faster Transactions”（Hashgraph 自认为胜过比特币和以太坊一筹）
-
“Hashgraph vs. Blockchain Is the end of Bitcoin and Ethereum near?”（Hashgraph 对区块链！比特币和以太坊的末日指日可待？）
-
“Hashgraph wants to give you the benefits of blockchain without the limitations”（Hashgraph 想要给你们带来无限牛逼的分布式账本）
-
……
简直一个项目要单挑所有区块链了！开头说的“拳打比特币，脚踢以太坊”已经算是非常谦虚的口号了。不过仔细研究以后，小 C 发现 Hashgraph 项目团队确实没有骗我——Hashgraph 真的是一个“银行级”的公用账本，一个只有银行级用户才用得起的账本。
Hashgraph是怎么做的？
小 C 在这里先来简单介绍一下 Hashgraph 的共识算法，对这部分比较熟悉或者不感兴趣的观众可以直接跳到下一节。
与 IOTA 所用的 Tangle 账本不同，Hashgraph 用了一种更规整的图结构“哈希图”去存储包含交易的区块（每个区块在 Hashgraph 中记为一个“事件”（event）），并通过一个 aBFT （Asynchronous Byzantine Fault Tolerant， 异步的拜占庭容错，指系统在不超过三分之一的节点被攻击者控制，且诚实的节点之间通信延迟可以被任意延长的情况下仍可以保证安全性）的共识算法来保证所有人对整个账本达成共识。
简单来说，Hashgraph 共识算法的基本逻辑就是：假设大多数参与者都是好人，那么当交易被足够多数人（比如三分之二以上的比例）见证以后，就可以确认这些交易的顺序以及它们是否有效了。只要系统里大部分人都是诚实的，那么多数人见证过的历史就可以沉淀为无法改变的共识。
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 少？
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 算法。
Hashgraph 的“银行级”性能
接下来，小 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 超高的安全性要求三分之二以上的参与者见证才能确认一笔交易，这样少数坏人再也无法修改公共账本。但是另一方面，这个机制也有非常严重的缺点——共识参与者的活跃性问题。
Hashgraph 共识参与者们必须非常活跃，否则就会因为见证人数不够而无法达成任何共识。在现实中任何一个去中心化的系统中，普通用户一般都是长期不在线的，能长期活跃在线的只有：1）银行和交易所；2）庄家；3）矿工（Hashgraph 没有 PoW，没有矿工） 以上都是。所以，一个由银行级和企业级用户维护共识的公共账本，当得起一句“银行级”的安全性。
对 Hashgraph 项目的建议
小 C 建议 Hashgraph 项目也不要总拿着“银行级”联盟账本的性能去找比特币和以太坊等公链碰瓷，都不是一个赛道上有什么好比的。还不如好好跟别的基于 pBFT（实用拜占庭容错）的公共账本比比孰优孰劣更有意义。
如果 Hashgraph 实在眼红公链这块蛋糕，也应该严谨地分析 Hashgraph 在公链环境下的安全性，然后用同口径的性能数据去跟别人比较，否则再怎么比也只是鸡同鸭讲罢了。本来嘛，如果 Hashgraph 只是做一枚安安静静的 BFT 账本，不要出来喊打喊杀地要做颠覆区块链的“Blockchain killer”，我们也不会想起来要拍它不是吗？就像裘千丈裘老前辈的职业规划如果是做一名魔术师或者杂技演员，那绝对是一位德艺双馨的老艺术家，也不会挨打对不对？
事实上，Hashgraph 项目也确实是按照联盟账本搞的，他们组织了一个由 39 个组织和企业构成的委员会去维护和运行这个分布式的账本。
至于开不起银行的普通用户嘛……我觉得支付宝和微信都是不错的企业级账本和 APP 平台。他们如果愿意把各地的机房拆分成不同的公司分别运营甚至卖掉几个的话，应该也能达到不输 Hashgraph 的“去中心化”程度。
顺便推荐一下我们的线下活动～在本期Conflux Meetup，我们为大家邀请到了Conflux CTO伍鸣、Conflux研究总监杨光、TOP Network Co-founder & CEO Steve Wei来一起聊一聊《下一代公链和DApps生态前景》。 点击报名
