在之前的博客中，我们已经从一个更为宏观的视角了解了Cosmos/Tendermint技术栈。在本文中，我们将深入介绍Tendermint共识引擎的共识层和网络层。Cosmos-SDK将实现区块链的应用逻辑，它与Tendermint共识引擎一起实现区块链的三层架构：应用层、共识层、网络层。Tendermint共识引擎将共识的产生与p2p广播以一种创新方式结合在一起。在软件工程中，模块化的设计相比于整体化的设计在代码复用、代码库的维护上有明显的优势。

 

自上而下：应用层(Cosmos-SDK),ABCI,Tendermint共识引擎(共识+p2p网络)

 

 

Tendermint共识引擎也被称为Tendermint。Tendermint也是开发Tendermint共识引擎和Cosmos网络的公司的名称。Tendermint共识引擎是一种底层协议，它由两个协议组成：共识算法和p2p网络通信。Jae Kwon和Ethan Buchman受到了Raft和PBFT的启发，把Tendermint设计成一种容易理解、对开发人员友好的算法。Tendermint也可以用在复杂的系统中。

 

新一代的PoS BFT共识算法都参考了Tendermint如何在公有链领域运用基于BFT的PoS共识的方案。我们把这一类成功的借鉴称为Tendermint BFT。它们都属于基于BFT的PoS(与基于链的PoS相对)。若想要进一步了解基于链的PoS与BFT PoS的区别，可以参考这篇文章：Casper vs. Tendermint。

 

现在大家应该对Tendermint有了大致的了解，先就让我们进入正题：到底什么是Tendermint？它是如何工作的？

 

Tendermint BFT 协议栈

 

 

比特币创造了当今所有我们耳熟能详的区块链加密币系统的技术基础。Tendrmint 协议与比特币系统有很多相似之处，因为他们都是通过区块来纪录信息，但在解决“拜占庭将军”的问题(共识机制)上又各采取了不同的解决方案。Tendermint的体系可以追溯到学术界关于分布式计算以及拜占庭容错的研究（参见Ethan Buhman 的论文：https://atrium.lib.uoguelph.ca/xmlui/bitstream/handle/10214/9769/Buchman_Ethan_201606_MAsc.pdf）。然而比特币的传奇故事是在多种电子现金支付系统失败之后（paypal除外）开始的，作为一种去中心化的无需进行审核的货币系统冉冉升起。

 

比特币的协议优化了去中心化的审核机制，这对于作为一种支付系统而诞生的比特币至关重要。而Tendermint，则是在多节点的广域网（如拥有百万节点的高节点数）中优化了分布式应用及数据处理方面的拜占庭容错。这种微妙的区别值得细究。

 

在全球的学术界里，关于广域网的拜占庭容错研究凤毛麟角，通常是基于拥有4–7个节点的单一管理权限的局域网研究。针对拥有大量节点及多个管理域下的广域网应用拜占庭容错的研究，基本找不到能应用于实践的重大突破。

 

2009年之前，当比特币向世界展示了其范式转变技术，也就是区块链概念时，如何解决节点数众多的广域网中的共识问题则一直找不到答案。尽管解决了“两将军问题”，但在理论以及分布式系统的研究方面，比特币并不是一个真正解决共识机制的算法。进一步完善拜占庭容错的研究还有很长路要走。

 

2014年，拥有计算机科学及系统工程背景的Jae Kwon设想了一种完全基于拜占庭容错的协议，通过POS(权益证明)作为底层的安全机制，可以应用于拥有数以百计节点的无许可环境。Tendermint从此诞生了。最终，这种基于POS(权益证明)作为主要的安全机制，并能在广域网中进行大量节点验证的的系统模型成为了一项异常复杂的工程实践，耗费四年时间才实现了项目公有链的落地。这个项目就是Cosmos,定于2018年夏上线。

 

 

模型

 

Tendermint是一种在部分同步的环境下的固定性协议。它能在网络和各个进程本身的延迟范围内实现吞吐量。在 Vlad Zamfir给出的三角形中，Tendermint落在这条紫色的边中的某一个点上。

 

Vlad Zamfir的三角形说明了在共识协议中的几类权衡

 

 

 

FLP 不可能原理

 

Theorem  “…我们呈现了一个令人惊讶的结论：在一个完全异步的共识协议下，即使一个线程的意外终止也可能导致共识过程的终止。” 也就是说，对于一个确定性的共识算法，在一个完全异步的环境中，如果出现了一个单线程的故障会导致共识的终止。

 

Dwork, Lynch和Stockmeyer在他们的文章Consensus in the Presence of Partial Synchrony，中写道：“部分同步系统是介于同步系统和异步系统之间的一种形态。在同步系统中，系统的延迟有一个上限……这个上限是关于信息从一个进程传递到另一个进程，关于不同进程的处理速度……在部分同步的系统中没有延迟的上限。我们需要设计一个可以在部分同步的系统中使用的共识协议，它不受系统延迟的影响。”Tendermint的诞生就是为了解决这个问题。Tendermint 是一个改进版本的 的DLS 协议。

 

 

共识算法

 

部分同步，同步和异步通信

 

让我们通过一个众所周知的协议作为参考，来探索同步的案例，这个协议就是比特币协议。比特币里有一个概念称为“已知固定上限”，指的是比特币系统在挖矿的过程中每10分钟生成一个区块的规律。为了保证比特币系统能稳定地发展并不断产生区块，比特币的协议中人为地设置了这个10分钟规律，这使得系统中的所有节点可以利用这10分钟的时间，来完成接收，打包，见证的工作，同时将产生的交易在整个网络里进行广播。

 

以太坊是另一个这类协议的典型，其同步假设的出块时间仅为15秒。以太坊的出块速度较比特币的10分钟大幅缩短，这使得以太坊系统在产出速度上有更高的效率，交易在全网广播所费的时间更短，但也正因为如此，结果形成了许多孤立区块，使矿工蒙受了损失。

 

Tendermint 属于一种在部分同步通讯下解决一致性问题的协议，部分同步系统介于同步与异步概念之间，我们有时也称之为“弱同步”系统。这意味着，Tendermint 基于时序假设进行了改良，与同步系统不同，部分同比系统的速度提升并不是基于系统参数的改进，而是基于网络的速度。

 

 

响应性与终止性

 

定义：终止性指的是任何进程在运行完成后应该给出一个最终决定。

 

传统算法的同步模型大多依赖于同步假设，不仅是要保证运算进程的完成，更是要保证安全性，诸如中本聪共识，Peercoin, NXT, Snow White, Ouroboros等，这些算法都是为了同步系统而设计并且都设定了先验边界。一旦同步系统中的先验边界失效，共识机制就会被打破，链就会产生分叉。因此，例如比特币设定的10分钟出块的规则，是出于一种对于主链安全性的适当保护。

 

Tendermint 则与之不同，只要出现问题的进程不超过1/3，那系统就不会出现分叉这样的异步性问题。这种特性使Tendermint成为了一种基于拜占庭容错的权益证明协议，而协议中安全性的保障又高于响应性能（CAP定理：分布式系统中，Consistency(一致性), Availability(可用性)，Partition tolerance(分区容忍性)不可兼容）。最终，Tendermint 区块链将在绝对大多数节点（比如超过2/3）完成共识见证后终止进程。

 

现在也有些同步协议存在于异步网络中，但是依据FLP不可能性（FLP impossibility是一个定理，它证明了在分布式情景下，无论任何算法，即使是只有一个进程挂掉，对于其他非失败进程，都存在着无法达成一致的可能。），这些协议不可能同时达成一致性决议。

 

确定性与非确定性 协议

 

在完全异步的情况下解决共识问题的非确定性协议潜在地依赖于随机预言和普遍地导致信息复杂度的开销，因为它们所有的通信都依赖于可靠的广播。在异步环境下，单个可靠的广播的开销大约和Tendermint中的一轮共识的花费是相当的。像HoneyBadger拜占庭容错这样的很多协议属于在异步环境下的非确定性协议一类。通常，它们要求在单轮的通信中要有三个可靠的广播实例。

 

相反Tendermint是一个完全确定性的协议；无论什么情况下在这个协议中都没有随机性。通过实现中的一个确定的数学函数，领导是很明确的被选举出来的。这样，我们能够在数学上证明这个系统是活的，并且这个协议能够保证做出决策。

 

轮流担任Leader

 

Tendermint 以加权的轮询方式在验证者集合，即如新区块的提出者们中循环产生。一个验证者和其委托人抵押的权益越多，它就有更多的权重，并且相应地它就会被更多的选为领导者。具体来说明一下，如果一个验证者和另一个验证者有着同样的权重，它们都会被协议以同样的次数选中。

 

对于这个算法如何工作的最简单的解释如下：

 

1、验证者的权重被设置

2、验证者被选择，轮到验证者来提议一个区块

3、权重被重新计算，在本轮结束后减少一定数量的权重

4、随着每一轮的进行，权重按照投票权利的相应比例逐渐递增

5、再一次选择验证者

 

实际对应的代码实现:

 

https://github.com/tendermint/tendermint/blob/master/types/validator_set.go#L50

 

 

因为协议可以很明确地选择区块的提案人，鉴于你知道验证者集合和每个验证者的投票权重，你可以在x, x + 1,…,x + n 轮次中准确地计算出谁会是下一个区块的提案者。因此，有评论者争论说Tendermint去中心化的还不够。当你可以预知谁会是领导者的时候，一个攻击者可以以这些领导者为目标并对他们发动DDoS攻击，而且很有可能使得这个链停止向前发展。我们通过在Tendermint中实现某个叫做哨兵架构的设计来减轻这个攻击路径的影响。

 

 

P2P网络协议

 

轮流担任Leader

 

随着Cosmos网络的影响范围不断变大，网络也会经常遭受攻击，比如说DoS。一个有效的哨兵节点架构将保证验证人节点的IP不被暴露出来，同时可以组织其他节点与验证人节点连接。 这样可以混淆验证人节点的真实位置。

 

也就是说，哨兵节点的架构是可选择的。验证人有责任维护一个抗攻击的全节点。 这是我们根据经济激励做出的额外假设。 假设是，验证人会希望采取所有预防措施，以保持容错，保持高可用，并最终在保持在共识过程中发挥其作用。 因为如果他们不这样做，他们会因为长期离线被强制剔除出验证人集合。

 

Peer Exchange (PEX) Reactor

 

Tendermint继承了比特币的节点发现机制。Tendermint沿用了btcd的p2p AddressBook，比特币在golang中的实现。在默认的的配置中将默认支持节点的发现。

 

 

Tendermint 实践

 

除了新颖的算法设计和学术术语之外，Tendermint还有什么用处呢?

 

坏消息是每天都有人觉得Tendermint没有用。好消息是应用程序开发人员可以跨越协议和最终用户之间的鸿沟。Tendermint被设计为可自定义且灵活的，足以满足任何设置的。无论是公共的还是企业的，他们都需要这样的一个共识协议。

 

对于想要在自己的区块链之上实现应用程序的开发人员来说，Tendermint非常理想。它是预先装配好的，所以如果开发人员想选择运行一个纯粹的基于BTF容错的POS共识引擎为他们的去中心化应用分区提供支撑，Tendermint可以很容易地做到这一点。

 

当用户使用Cosmos-SDK实现他们的高级业务逻辑时，有趣的部分就出现了。为了与Tendermint的共识/网络层进行连接，我们通过一个Tendermint套接字协议来完成，我们称之为区块链接口，或者ABCI。

 

- Application Layer: 

Cosmos-SDK (Blockchain Application Framework)

 

- Cosmos-SDK Alpha Release

 

- TendermintABCI：

http://tendermint.readthedocs.io/projects/tools/en/master/introduction.html#abci-overview

 

 

正在进行的研究

 

目前，我们正在深入研究BLS签名，这可能会导致Tendermint块头的大小从3.2 KB(带有~100验证器)减少到64字节。

 

我们也有一种设计，可以在安全的方法中随机化循环选择提议者的函数，使DDoS的下一个提议者更加困难，但是最初的步骤是Sentry节点架构。

 

 

Cosmos Academy成立Meetup!

 

我们将在加州伯克利举办一场即将到来的聚会。资深的BFT分布式系统研究人员Zarko Milosevic将会负责对Tendermint的所有内容进行问答环节。我们将直播这次聚会，并在Cosmos Network的YouTube频道上进行广播。

 

 

额外的资源

 

- 请阅读下面对Zarko Milosevic（Tendermint Core高级研究员）的采访：

https://github.com/tendermint/aib-data/blob/develop/medium/TendermintBFT.md

 

- Jepsen的Kyle Kingsbury展示了Tendermint BFT:

https://v.qq.com/x/page/b06787h6drf.html

 

- 关于Tendermint的技术规范，请参阅Zach Ramsay的Readthedocs

http://tendermint.readthedocs.io/projects/tools/en/master/

 

- 阅读Jae Kwon最初的Tendermint白皮书。

https://tendermint.com/static/docs/tendermint.pdf

 

- 阅读Ethan Buchman的the History of Distributed State。

https://atrium.lib.uoguelph.ca/xmlui/bitstream/handle/10214/9769/Buchman_Ethan_201606_MAsc.pdf

 

- 在软件工程的每日播客上，听一听分布式状态与Ethan Buchman的历史。

https://softwareengineeringdaily.com/2018/03/26/consensus-systems-with-ethan-buchman/

 

- 在Zaki Manian比特币播客网站，听一下早期区块链生态系统。

http://thebitcoinpodcast.com/hashing-it-out-5/

 

特别感谢：Cosmos&IRISnet China Translation group的成员，Bryan、Arthur、Mike&Suyu

来源 Cosmos互联链