在之前的几期秘猿科技小课堂中，我们对比分析了 PoW 和 PoS 的优劣，以及我们 CKB 是如何改进比特币的 PoW 协议的。这一期是共识部分的最后一期，我们带大家综合了解一下区块链共识，以及如何用一个简单的分析框架来解剖区块链共识。
秘猿科技区块链小课堂第 30 期
[1] 延迟为交易发出到被共识确认所需要的时间。低：<10s，中：10s-600s，高：>=600s
[2] 保持共识性能的情况下允许的共识节点数量。低：<100，中：>=100，高：没有限制
[3] Bitcoin 的 Nakamoto Consensus 具有很低的通讯开销（communication overhead），但由于共识参数的设定（10 分钟区块间隔，~4MB 区块容量）导致带宽利用率低。
[4] EOS 的宣传中说的是 BFT，但是与一些朋友交流得知现在用的依然是 NC，也就是说 EOS 的 DPoS 与 BitShares 的 DPoS 应该是一样。
框架思路
共识算法是一个很大的话题，在区块链出现之前，分布式系统和数据库领域都已经有很多的共识算法的研究和沉淀。但区块链的共识与之前的研究又有非常大的不同，如果不注意很容易掉进传统共识的老套路里面。实际上不仅仅是区块链有自己的独特需要，我的感觉是数据库会议上的共识研究和分布式系统上的共识研究也是有不小的区别。其实这非常好理解，因为场景不同嘛，设计自然不同。
本文尝试提出一个分析区块链共识的简单框架，方便将不同的区块链共识放到一起来比较。
基本要求
共识的基本度量包括两个方面，正确性和性能。正确性简单来说包括：
- 一致性(Consistency) – 节点最终能看到相同的本地状态
- 活性(Liveness) – 请求 / 交易总会在有限时间内被处理
正确性是最最基本的要求，这也是大部分区块链共识都能做到的。要在异步网络中始终保证一致性和活性是一个非常难的任务，因此共识设计通常会选择保证一点而在一些特定情况下放弃另外一点，例如 Bitcoin 使用的 Nakamoto 共识选择优先保证活性，而 BFT 共识则优先保证一致性。
性能包括：
- 吞吐量(Throughput)- 单位时间内系统可以处理的请求数量
- 延迟(Latency)- 一个请求 / 交易从发起到处理完毕 / 完全确定所需要的时间
对吞吐量和延迟的影响因素很多，例如共识节点的数量，共识的消息复杂度，消息验证需要的时间，共识可用的带宽，共识设计的倾向等等。一般来说，吞吐量和延迟也难以两全，这是因为共识的消息复杂度有一个下限：对于每一轮共识，参与共识的节点至少要收到一次消息（否则连要共识的东西是什么都不知道）。如果要低延迟，就要尽快对每个请求 / 交易的达成一致，意味着单个请求 / 交易需要更高的消息复杂度；如果要高吞吐，就要尽可能的对请求 / 交易进行批量处理，以此降低单个请求 / 交易的消息复杂度，但也会造成高延迟。
对于共识性能，Nervos 研究团队的张韧提出的一个比较有参考性的指标是共识对带宽的利用率：给定相同的带宽，共识对带宽的占用越低，共识的吞吐量越高。
区块链共识的特点
动态的参与者集合
无论是 permissionless（翻译成“无需许可”太绕口了，用“公有链”又不是很准确 2，这里还是用单词）还是 permissioned blockchain，最重要的一个特征是它是一个长期运行的开放系统。长期运行和开放叠加的结果是，共识的参与者会一直变化，每隔一段时间，总会有老的共识节点离开，新的共识节点加入，共识参与者是一个动态集合。如何处理共识参与者的动态变化，是区块链共识的一个核心问题。
与区块链共识不同，传统的共识研究往往先假设一个固定的参与者集合，然后研究如何在这个集合内达成共识，偶尔讨论参与者集合变化时的处理，基本上不关心参与共识需要什么样的资格。研究的重心在于如何保证共识的正确性（e.g. 一致性与活性），形成共识集合的方式只是个附属课题。传统共识的应用场景往往是中心化控制的网络，增加或者减少的服务器都是自己的，形成这样的侧重也很自然。
数量众多的参与者
去中心化是 permissionless blockchain 共识协议的一个独特目标。我们通常用参与共识的门槛来度量去中心化程度（为什么这是一个好的度量？），参与门槛越低，去中心化程度越高。低参与门槛的自然结果是共识参与者的集合可以非常的大，因此共识协议的设计必须考虑到这一点，保证共识效率不会因为参与者的增多而下降。
最小的信任模型
执行共识算法的目的是为了能对一个计算请求产生一致的计算结果，在这个过程中一定会有发起请求的节点和处理请求的节点。在传统共识模型中，有的完全在请求处理节点集合内部执行共识算法，有的是由请求发起节点和处理节点一起执行共识算法，无论何种情况，信任边界一般是在请求发起节点和请求执行节点之间，发起节点将计算请求发送给执行节点，执行节点计算出结果后返回给发起节点，发起节点信任执行节点的计算结果（反过来，执行节点不一定信任发起节点的消息，如果发起节点参与共识过程的话）。
区块链共识的信任模型则大为不同，对信任的要求往往要小的多。在 permissionless blockchain 网络中，同一个节点即发起交易又参与共识，节点对于共识结果要进行验证，并不是简单的信任其他节点的共识结果。以 Bitcoin 为例，如果一个全节点参与挖矿，它就同时是一个发起请求（交易）的节点和处理请求（交易）的节点。即使它只想做一个安静的全节点，不参与挖矿，它也会自行验证收到的请求处理结果（区块），并不信任其他共识节点提供的结果。这样的全节点只是选择跟随多数算力选择的交易排序，不相信多数算力给出的交易结果。这是一个最小的信任模型。
SPV/ 轻节点使用一个比全节点更强的信任模型（更强意味着对信任的假设更多），并不验证交易的执行，只验证区块头的有效性。如何验证区块头的有效性则是区块链共识设计的另一个核心问题。如果只是通过对区块头附带的非对称签名来验证有效性，这个信任模型基本上和传统共识的信任模型是等价的，因为传统共识中的请求处理节点也可以对结果附加签名，这个模型在结合动态参与者集合时会遇到一系列的问题，例如大家熟知的长程攻击。如果是通过 PoW 来验证区块头有效性则天然没有这些麻烦，主流的研究方向是在于如何进一步提高区块头的验证效率。
一个简单的分析框架
根据以上的分析，我们可以整理出一个简单的区块链共识分析框架，用于比较各种区块链共识：
- 进入方式 * – 购买算力 / 抵押代币 / …
- 出块方式 * – 轮流出块 / PoW 随机选择 / 链上伪随机 / VRF 随机选择 / …
- 共识方式 * – Nakamoto Consensus / BFT / …
- 退出方式 * – 停止挖矿 / 解除抵押 / …
- 一致性 – 可以容忍多少恶意节点 / 算力 /Stake/…
- 活性 – 可以容忍多少恶意节点 / 算力 /Stake/…
- 延迟 – 交易被完全确认 (被推翻的概率小于 x) 所需要的时间
- 带宽效率 – 共识对带宽的利用率，越高越好
- 节点数量 – 共识节点的数量上限是高还是低
举例说明：
[1] 99% 的确定性
[2] 考虑自私挖矿
[3] 无论多小的正常算力都有机会出块，但是平均延迟会增加
[4] https://github.com/tendermint… 6
[5] https://medium.com/nervosnetw… 6
对于一个区块链共识协议来说，前四点（带 *）基本上决定了后面的特征。通过这个框架也容易看到，我们通常所说的“PoW 共识”或者“PoS 共识”是非常模糊的描述，PoW/PoS 仅仅是选择出块节点的方式，不能表达具体的共识过程是什么样子。我们甚至可以设计一些非常混搭的共识协议，例如设计一个需要通过抵押代币来参与，通过 PoW 来选择出块节点，通过 Nakamoto Consensus 形成最长（重）链的协议（可以给它取名叫 StakingPoW，完美结合 Staking 热点），或者是设计一个需要通过 PoW 来参与（必须提供满足一定难度的 PoW 才能参与共识），通过 VRF 来选择出块节点，通过 BFT 来达成共识的协议（这个可以起名叫 PoW+VRF/BFT，让人一看就从心底油然升起专业的感觉）。
激励分析
在上面的框架之上，我们还可以叠加一个在传统共识中没有的维度：共识激励。区块链在共识中引入了经济激励，通过机制设计将纳什均衡与系统目标融合在一起，引导参与者遵守协议，共识参与者的效用函数可以方便的以其经济收益（即获得的奖励减去参与共识的成本）来衡量。共识奖励往往通过系统内原生代币实现，奖励价值由代币价值决定，在一个正确设计的共识协议中参与者应该按照付出的多少获得相应的回报。共识成本的组成比较复杂，对应上面的框架，我们需要分析共识的进入成本，出块成本，共识成本，退出成本，这些成本共同构成了节点参与共识的成本。正确的共识激励对网络的安全性和去中心化程度都有影响，因此激励分析是共识分析的一个重要部分。