这种做法的弊端在之前的POW算法容易被51%攻击的分析中已经很明显了——我们当然可以对于所有的资源都做出“大多数人都诚实的假设”，但是，如果这个假设在现实中并不成立，那么采用这个假设证明了安全性也毫无意义。

另一方面，共识算法的安全性是与它的应用场景相分离的。对于一个共识算法是否安全，我们要么通过BFT证明“它可以达到拜占庭容错”，能够对于所有数据达成一致和活性，要么通过Bitcoin Backbone Protocol的模型证明我们可以得到一个增长的，一致的账本。

也就是说，前者，我们将区块链视为一个拜占庭容错的分布式数据库，后者，我们将区块链视为某种类似比特币的分布式账本。然而，在此之上区块链的应用却已经远超分布式数据库和账本的范畴了。例如，对于分布式账本，一致性的重要性高于活性(所以可能很多人会认为空块不算是对于比特币安全性的破坏)。

因此，比特币的POW算法并不保证交易的活性，而仅仅保证能够被上链的交易的活性，同时用交易费的模型鼓励矿工尽可能地将交易添加上链，即保证“交易费给得足够多”的交易的活性。

然而，当将这种共识算法用于其他对于交易活性要求高的应用时就可能会出现严重的问题——例如FOMO3D实际上就是受到了针对于以太坊交易活性的攻击，而尽管比特币以及以太坊的模型不保证交易活性这件事对于业内人士都不是秘密，但是不可否认的是，既然以太坊或者其他的区块链具有这样的应用，在共识算法安全性分析的时候把这种情况排除在外，本身也说明了这个模型并不完备。

因此，我们需要一个更实际，从应用出发，面向目标和场景的对于区块链安全性的评价标准，并且：

1、相比于每一个机制的可证明的安全性，我们更关注这个系统是不是能够达成它应有的功能。

2、相比于在一些条件限定下的绝对安全性，我们更关注在现实语境下的相对安全性。这点和我们之前的分析是一致的，也就是说，我们更关心——想要破坏这个系统，使得它没法做它该做的事情的代价有多大。

3、然后，对于“应有的功能”相对应的特性，我们应该根据实际情况来分析他们的重要性——例如，对于货币，一致性、活性、抗审查、匿名的需求取决于什么样的场景。如果黑市是需求，那么匿名可能需要摆在活性之上，但如果把交易和支付作为场景的话，我们应该参照一个支付平台的要求去考虑他们之间的权重。

以上的定义并不严谨，但是毕竟这只是一个提议，我们不是在写论文。

从这个角度来讲，其实对于数字货币的共识算法而言，我们并不用去考虑51%攻击，长链攻击，无利益攻击这些方式和相应的条件，也不用去关心在怎样的假设下通过什么样的算法可以防止他们的出现。

我们该关心的的问题是——

1、我们需要付出多大的代价才能破坏一致性，进行一次双重支付攻击：于是，我们可以判断这个系统可以承载多少价值，而一笔交易的数额超过多少的时候，我们就需要考虑双重支付这种可能，并且相应地提高确认时间，或者，仔细审视各个节点的动态。

2、我们需要付出多大的代价才能破坏活性，每延迟一次出块或者一分钟达成共识：于是，我们可以知道需要即时确认的交易中，我们有可能会遭到多大的损失。然后，对于FOMO3D这样的“游戏”，我们会知道当一个币卖到多少钱的时候，就已经可能不安全了。

3、我们还需要知道需要付出多大的代价才能破坏抗审查：于是，我们可以知道，比特币其实并不是一个完全自由的货币，当代价足够高的时候，我们是可以消灭掉某个地址的活性的。

4、然后，对于匿名货币，我们需要知道多大的代价，可以破坏匿名性，于是可以追踪到一笔钱的来历，或者是标记一个地址的身份。

以上，是对于“货币”这个功能而言的——这是我们的起点。

而之后，最理想的状态是，我们应该对于区块链所能实现的所有功能，判断它们所需的性质，然后，量化它们的安全性。

那么，在这里，去中心化的位置在哪里呢?

对于去中心化的要求，已经融入安全性的标准之中了——毕竟，去中心化是手段而不是目的：一个过于去中心化的系统，将面临着和中心化系统同样的风险，即作恶的成本不可控。

而同时，一个过于中心化的系统中，共识算法也将失去意义。

因此，在安全性标准中，我们必须也将它的去中心化程度纳入考量。

1、我们需要衡量实际参与共识节点的大节点的数量。

2、我们需要知道这些节点的信息，来评估他们在链外获益或者合谋的可能性。

3、同时，我们还需要确定，这些节点确实有能力维护这个系统的安全。

正如之前所说，一个理想的，安全的区块链系统，是由足够多数量的，身份已知的大节点来维护的。

于是，我们需要知道：

1、他们是否有足够的动力来维护这个系统——他们是否有足够的收益。

2、这个系统的结构是否稳定——他们是否也能够决定系统的发展方向。换言之，我们怎么保证未来整个系统还是有足够的大节点来维护，而不是共识节点会由于系统未来的发展方向与期待不符而逐渐退出或者分叉，重新导致中心化。因此，我们需要评估的决策机制是否能够代表共识节点的权益。

3、同时，我们还需要保证，所有在系统中有利益的群体，都应该能够参与共识。

于是，我们需要激励机制，链上治理等等其他的机制——

一切，归根结底都是安全问题。

写在最后

这是我关于POW和POS讨论的最后一篇，这三篇的内容和长度都远远超出我的预期，可能是进入这个领域以来看到听到的东西太多，积攒了很多东西不吐不快的缘故。

之前，我写过专业的在区块链领域的顶会上发表的学术论文，也一直致力于在知乎上写一些客观的和中立的科普性文章，我一直致力于避免的，就是在这个本来就混乱的行业中引入新的混乱——因此，我一直只写一些已经成为这个领域基础的论文和技术，但不愿意写太多新的、未经证实或者检验的结论，尽管有些结论我认为是正确的。甚至于，即便我的文章已经被接受甚至发表，我也不太愿意在我的专栏里介绍它们。

然而这一个系列和之前我写过的所有文章都不同，这一篇里更多的是个人的观点和判断，其中，我可能提出了不少“政治不正确”的，“大家不喜闻乐见”的，“在业内尚有争议”的，或者“所有人都知道但是没有人愿意说”的观点，因此，自从文章发表以来也或多或少引起了一些争论——而这些都是我原来一直想要避免的。

之所以做出这样的改变，其实关键的原因还是我在文中说的那点——资本和市场追逐新噱头的脚步是不会停下等技术发展的，于是，当这个领域所有的人似乎都已经开始盲目乐观地考虑长期发展的时候，我们需要反思一下——我们做的这些东西，真的“够安全”吗?

什么是Hashgraph算法?Hashgraph算法最早是由 Leemon Baird 博士在 2016 年发表的一篇论文“The Swirlds Hashgraph Consensus Algorithm: Fair, Fast, Byzantine Fault Tolerance”(https://swirlds.com/downloads/SWIRLDS-TR-2016-01.pdf)”上公开，根据其介绍，Hashgraph 算法实现了异步拜占庭容错(ABFT)，因而能容纳非常高的吞吐量并能非常快速的处理交易(官网提供的数据显示，在真实环境下可以达到惊人的 250k TPS)。

Hashgraph算法简介

Hashgraph 是一种异步拜占庭容错算法(ABFT)，它跟我们目前常见的 PBFT 算法最大的不同就是它是完全异步的。我们知道 PBFT 算法能支撑的网络规模是非常有限的最大原因就 PBFT 模型的通信复杂度是 O(N^2)，随着节点数量的增加，需要通信的消息数量呈指数级别的上升。而 Hashgraph 突破性的抛弃 PBFT 中使用的消息同步机制，使用异步 BFT，通过保证最终确定性来确保算法的高效和安全。

Hashgraph 采用的是 DAG 数据结构，这跟当前的很多开源链(比如 Iota，byteball, nano 等)是类似的，因为它们都采用 DAG 作为底层数据结构模型。但是 Hashgraph 最特别的一点是，它无需中心权威节点，而是依靠独特的 Gossip about Gossip 和 Virtual Vote 两大机制来保证了算法可以在纯异步的环境中高效运行，并且通过绝对多数(超过 2/3 节点)强可见(强引用)机制来保证了共识结果的正确性(安全)。

Hashgraph 算法是一种拜占庭容错算法，它要求节点数量是相对固定的(总量为 N 需要预先设定)，这样的话，它就可以通过大于 2/3 忠诚节点的比例原则来达到拜占庭容错。这跟当前公链模型下(比如 DAG 主链，POW，POS 等)这些算法在达到共识的条件上有一些区别，所以更适用于私链(或联盟链)。但是，由于其独特的性质(在保证去中心化的同时不需要繁重的工作量证明)，Hashgraph 在未来的公链也有相当潜在的使用价值。

最后，再介绍一下 Hashgraph 跟其他开源项目在运作模式上的区别。

根据原作者发布的白皮书介绍，Hashgraph 仅是一个算法的名字，它既不是区块链项目(比如比特币，以太坊这种完整的可运行的系统)，也不是开源的。它是由发明它的 Leemon Baird 博士所创建的Swirlds, Inc公司负责掌控，并运营在 Hedera 项目(https://)之下。Swirlds 公司对该算法申请了专利并进行了很强的技术保护，它致力于在企业之间以合作的方式来运作和使用基于 Hashgraph 开发的应用。

从这里我们可以大致看到，Hashgraph 是按照一个相对传统的方式在运作。虽然其核心算法的源代码并不公开，它还是做出了一定程度的开放来使得整个区块链社区和开发者受益，比如对外提供 SDK(https://dev.hashgraph.com/)。由于 Hashgraph 算法是用 Java 和 LISP 实现的，因此很多基于 JVM 的语言都可以在其之上构建应用程序。当然，社区的开发者也基于 Hashgraph 公开的算法(论文)实现了许多其他语言的版本(比如 Go，Python, Javascript 等)，由于算法的简洁和优雅，已经有越来越多的开发者被吸引。

Hashgraph算法原理

介绍完了 Hashgraph 的相关背景，我们接下来进入主题，也即算法原理。

实际上，算法的大部分内容在论文中都有介绍，不过，毕竟论文发表的时间早，其中难免缺失许多细节。因此，Leemon 博士在其发表之后的数年时间内又不断对该算法做了更多更细致的描述和改进。在 Youtube 上也有它对该算法的一个长篇介绍，不过很多人看完仍然表示似懂非懂，不好理解。因此，这篇文章致力于把算法用更易懂的方式解释得更通透一些。

在介绍算法之前，先了解论文中所提出的一些概念，Event，这个是 Hashgraph 中最基本的元素和概念。

在 Hashgraph 中，使用一种叫Event的数据结构来代替我们常见的区块链(比如比特币)中的 Block 概念。Event 由每个节点自行创建，它主要包含四类元素：交易集合，时间戳，以及对两个 Parent Events 的引用哈希。

在传统的区块链中，新产生的区块只能是只能有一个先导区块的，在 Hashgraph 中，每个 Event 必须要链接两个 parent Events，其中一个必须是自己，而另一个则可以是任何一个从其他节点发来的 Event。

我们来对比一下传统区块链的结构和 Hashgraph 的结构之间的区别，如下：

Hashgraph 算法的核心技术点是两个部分：谣言算法(Gossip about Gossip)和虚拟投票(Virtual Voting)。

接下来，我会一步一步详细介绍!

Gossip About Gossip

Hashgraph 共识的机制和 hashgraph 结构的构建是通过 Gossip 过程来完成的(更多关于 Gossip 机制的介绍，可以参考我这篇文章：“P2P 网络核心技术：Gossip 协议”)。

Gossip 简单来说就是，节点随机选择一个可以连接的邻节点，向其发送一条信息(Event)。而 Gossip about Gossip 则是，收到 gossip 信息的节点，对该 gossip 信息进行签名，并且再把该签名打包进一个新的信息中，并随机发送给网络中的任一节点。这样，每个节点发出的 Gossip 信息都包含了对其收到的前一个 Gossip 信息的签名验证，实际上就是做了一个见证(Witness)工作。

注意这里的 Gossip 过程是非常简单的，收到 Event 信息的节点可以向任意一个或多个节点继续 Gossip 新的 Event。每一次 Gossip 都是对前一次信息的背书和见证。

Local hashgraph copy

我们用小写的 hashgraph 表示该算法底层使用的数据结构，参与共识的每个节点都会保存一份完整的 hashgraph 副本图，初始时(genesis)，每个节点上的这个副本图都是空的，当开始有节点产生 Event 之后，就会在自己的 hashgraph 副本图上进行记录。

比如，每个节点都创建第一个 Event 时，他们各自的副本图如下：

当 A 收到 C 发来的 Event 时，A 就会更新本地的 hashgraph 副本，如下：

同时，A 还会基于 Event_a1 和 Event_c1 创建一个新的 Event，并 Gossip 出去，如下：

假设刚才在 A 收到 C 的 Event 时，C 也收到了 D 的 Event，那么各个节点的 hashgraph 副本图则会显示如下：

某个时间点之后，大家都收到了彼此发给对方的消息

可见，在节点相互 Gossip 通信的过程中，它们各自 hashgraph 副本的内容都不尽相同，但是有一点非常重要的就是，每个节点都会忠实的记录自己所创建的所有 Events。