Cosmos Blog: Tendermint 101

“

译者按：这是一篇2018年的文章， 看起来有点旧， 不过考虑到Cosmos的几大基座:Cosmos SDK, Tendermint 以及IBC， 不妨温顾下Tendermint的运行原理。

原文链接^[1]

”

相关说明

• 有关定义，请阅读Chjango Unchained^[2]的 Primer。

• Tendermint 共识算法的最新完整规范，由Ethan Buchman^[3] 、 Jae Kwon^[4]和 Zarko Milsosevic 撰写。

• 有关 Cosmos/Tendermint 软件堆栈的概述，请阅读Gautier MARIN^[5]的 Cosmos 的价值主张。

• 观看Sunny Aggarwal^[6]的 Cosmos 网络拓扑概述

介绍

对于刚开始接触 Tendermint、Cosmos 网络以及两者交叉点的新人来说，可能会信息过载。我们已经从抽象层面上写过 Cosmos/Tendermint 堆栈^[7]，但在这篇文章中，我们将更深入地探讨 Tendermint Core 的共识和网络层。

所述软件栈的设计由应用层（Cosmos-SDK）、共识层和网络层（Tendermint Core）组成。Tendermint 以一种全新的方式将共识与 gossip 的p2p协议结合起来。

使用单体架构在计算机科学中通常是不好的做法，因为这样做会导致难以重用已有的组件，并且会导致代码库的维护过程变得复杂^[8]。

自上而下：应用层（Cosmos-SDK）、应用区块链接口（ABCI）、Tendermint核心栈（共识算法+p2p网络协议）。

要点：语义。Tendermint Core 是一款软件，与 Tendermint 同义，后者是实施 Tendermint Core 和 Cosmos Network 软件堆栈的组织。

从技术上讲，Tendermint Core 是一个底层协议，它实际上由两个协议构成：共识算法和P2P网络协议。

Jae Kwon 和 Ethan Buchman 受到 Raft 和 PBFT 背后的设计目标的启发，将 Tendermint 指定为一种易于理解、对开发人员友好的算法，同时进行算法复杂的系统工程。

新一代 BFT Proof-of-Stake (PoS) 共识算法借鉴了 Tendermint 对公链领域和 BFT 适配的元素。这种使用的就是我们所说的 Tendermint BFT，并且更普遍地被归类为基于 BFT 的 Proof-of-Stake（与基于链的 Proof-of-Stake 相对应）。

有关基于链与基于 BFT 的 PoS 的介绍，请参考：Casper 与 Tendermint^[9] 。

交代完相关背景后让我们进入第一个环节：什么是 Tendermint，它是如何在更高层次上工作的？

Tendermint BFT 栈

比特币是我们今天所知道和喜爱的所有基于区块链的密码系统的祖先。Tendermint 协议与比特币有共同点，因为这两个协议都记录了区块链上的所有内容，但它们各自为拜占庭将军问题（也称为共识或“协议”问题）提供了独特的解决方案。

Tendermint 的血统可以追溯到分布式计算世界和学术界的拜占庭容错 (BFT) 文献（参考 Ethan Buchman 的论文^[10]）。

而在比特币的起源故事中，在以前的电子现金系统（PayPal 除外）的多次失败尝试之后，比特币作为一个抗审查的去中心化货币系统从灰烬中崛起。

比特币协议优化了抗审查能力，尤其是它作为支付系统的能力。另一方面，Tendermint 优化了通用拜占庭容错分布式应用程序和广域网 (WAN) 中的数据处理，例如数百个节点（高节点数）。这种区别是微妙的，值得更深入的研究。

就上下文而言，在学术界，对 WAN 的 BFT 系统进行的研究很少，并且仅针对少数节点（最多 4 到 7 个）并且始终针对单个管理域。对于具有大量节点和多个管理域的广域网的 BFT 系统，在实践中没有广泛的实践。

在 2009 年之前，当比特币向世界引入一种范式转换技术——区块链的概念——时，广域网设置中多节点数的共识问题基本上没有得到解决。

然而，尽管解决了两位将军的问题，但在分布式系统研究领域的纯理论意义上，比特币并不是真正解决共识的算法。BFT 领域的进一步工作远未完成。

2014 年，拥有计算机科学和系统工程背景的 Jae Kwon 设想了一个纯粹基于 BFT 的协议，该协议将在以权益证明 (PoS) 作为底层安全性的无许可设置中扩展到数百个节点机制。于是创建了Tendermint^[11] 。

因此，这个以 PoS 作为 WAN 中大量验证节点的主要安全机制设计的系统模型被证明是一项非常复杂的工程工作，在公链环境中实施了将近 4 年。这个场景就是 Cosmos，计划于 2018 年夏天推出。

模型

Tendermint 被建模为确定性协议，处于部分同步状态，在网络和各个进程本身的延迟范围内实现吞吐量。看到Vlad Zamfir^[12]三角形中紫色的轮廓了吗？Tendermint 落在左下角的某个地方。

容错共识协议的Vlad Zamfir^[13]三角权衡

FLP 不可能

定理^[14]：“……我们展示了一个令人惊讶的结果: 没有一个完全异步的共识协议能够容忍哪怕是一个未宣布的进程死亡。例如，如果至少有一个进程可能失败，那么在具有确定性协议的纯异步网络中就无法解决一致性问题。

由 Dwork、Lynch 和 Stockmeyer 在他们的论文《部分同步的情况下达成的共识》中^[15]定义：“*部分同步介于同步系统和异步系统的情况之间。在同步系统中，有一个已知的固定上限......关于一个消息从一个处理器发送到另一个处理器所需的时间，以及一个已知的固定上限......关于不同处理器的相对速度。

在一个异步系统中，没有固定的上限……问题是设计在部分同步系统中正常工作的协议，而不管边界的实际值如何*…… Tendermint 正是为了解决这个问题而诞生的。[因此，Tendermint 是](https://tendermint.com/static/docs/tendermint.pdf "

因此，Tendermint 是")上述DLS 协议^[16]的修改版本。

共识算法

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

我们来探讨一下同步情况，用一个著名的协议作参考：比特币协议。在比特币中，有一个 "已知的固定上限"。这是指10分钟的区块时间。为了让比特币网络继续创建区块，该协议人为地强加了一个时间假设，给整个节点网络整整10分钟的时间来监听、收集、验证和gossip在其对等网络中传播的交易。

以太坊是另一个协议示例，该协议以平均 15 秒的块时间进行同步假设。虽然 15 秒比 10 分钟快得多——让以太坊网络获得更高吞吐量的好处——但这是以牺牲矿工为代价的，因为这会导致更多的孤块；交易通过其网络传播的时间更少。

Tendermint属于一类解决部分同步通信下的共识的协议，其中，部分同步的系统模型在同步和异步之间交替出现；我们有时将这种模型称为 "弱同步"。这意味着，Tendermint确实依赖于时间假设，以便取得进展。然而，与同步系统相比，处理的速度并不取决于系统参数，而是取决于真实的网络速度。

活性 & 终止

定义：“终止属性只是每个正确的处理器最终应该做出决定。 ”

Nakamoto 共识、Peercoin、NXT、Snow White、Ouroboros 等的算法在同步系统模型中，依赖于同步假设，不仅是为了进程终止，也是为了安全。那些为同步系统设计的算法总是有固定的界限，这些界限是已知的并且总是成立的。如果同步边界不成立，共识就会被打破，链就会分叉。例如，比特币的 10 分钟出块时间是适当保守的，因为要保证安全。

相比之下，如果少于 1/3 的进程有故障，Tendermint 永远不会在存在异步的情况下分叉。此属性使 Tendermint 成为基于 BFT 的 PoS 协议，在该协议中，它严格地偏爱安全性而非活性（参见：CAP 定理^[17] ）。

因此，Tendermint 区块链将暂时停止，直到绝大多数（即超过 2/3）的验证者集达成共识。

现在，有一些共识协议可以在纯异步网络中工作，但是，根据 FLP 不可能定理，它们不能同时是确定性的。

确定性 vs 非确定性 协议

在纯异步情况下解决共识的非确定性协议有可能依赖于随机Oracle，并且通常会产生很高的消息复杂度开销，因为它们的所有通信都依赖于可靠广播。

在异步环境下，单个可靠广播的开销成本大约相当于Tendermint^[18]的一个^[19]round。

像HoneyBadger BFT这样的协议就属于这一类异步下的非确定性协议。通常情况下，它们在一轮通信中需要三个可靠广播的实例。

相反，Tendermint 是一个完全确定性的协议；协议中没有任何随机性。领导者是通过实施中定义的数学函数确定性地选出的。因此，我们能够在数学上证明系统是实时的，并且保证该协议能够做出决定。

轮值领导人选举

Tendermint以加权轮流的方式在验证人组，即区块提案人中进行轮换。验证人委托给他们的股权，即投票权越多，他们的权重就越大，他们被选为领导人的次数也会按比例增加。举例来说，如果一个验证人和另一个验证人拥有相同的投票权，他们被协议选中的次数相等。

该算法如何工作的简要解释如下所示：

1. 确定验证者权重
2. 验证人当选后出块
3. 权重重新计算，回合完成后权重减少
4. 随着每一轮的进行，权重与投票权成正比地增加
5. 验证人再次被选中

• 这是实际的代码片段：( GitHub^[20] )

因为协议确定性地选择区块提议者^[21]，假设您知道验证者集和每个验证者的投票权，您可以准确计算出下一个区块提议者将在轮次x 、 x + 1 、...、 x + n中是谁。因此，批评者认为 Tendermint 的去中心化程度不够。

当您可以预见谁是领导者时，攻击者可以瞄准这些领导者并对他们发起 DDoS 攻击，并可能阻止链的进展。我们通过在 Tendermint 中实现称为哨兵架构^[22]来缓解这种攻击。

P2P 网络协议

哨兵节点架构

一个正确设置的验证器将永远不会暴露其验证器节点的IP地址，也不会接受进入的连接。一个正确设置的、防御良好的验证器会主动生成哨兵节点^[23]，作为网络的全节点代理，以混淆其验证器节点的真实位置。p2p层的IP地址永远不会暴露。

也就是说，哨兵节点架构的优势是可以选择的；验证者有责任维护一个容错的完整节点。这就是我们根据密码经济激励机制进行协议外假设的地方。

假设是，验证者希望采取所有预防措施，以保持容错性和可用性，并最终在保持网络运行方面发挥自己的作用。因为如果不这样做，他们会因为离线超过一定时间而被踢出验证者集合。

对等交换 (PEX) 反应器

Tendermint 借鉴了比特币的对等发现协议。更具体地说，Tendermint 采用了来自btcd^[24]的 p2p 地址簿，这是 Go语言版本中的比特币实现版本。PEX 默认启用动态对等发现^[25]。

实践中的 Tendermint

那么，除了花哨的算法设计和学术术语之外，Tendermint到底有什么用？

坏消息是，普通人不会发现Tendermint的作用。好消息是，应用程序开发人员可以弥补协议和最终用户之间的差距。Tendermint的设计是可定制的，并且足够灵活，以适应任何需要共识协议的环境，无论是公链还是企业环境。

Tendermint 非常适合希望在自己的区块链之上实现应用开发人员。它是预先组装好的，因此如果开发人员选择使用纯权益证明(PoS)、基于 BFT 的共识引擎来为他们的dAppzone^[26]提供动力，他们可以很容易地做到这一点。

当用户用Cosmos-SDK实现他们的高级业务逻辑时，有趣的部分就来了。与Tendermint共识/网络层的接口是通过Tendermint套接字协议完成的，我们称之为应用区块链接口，或称ABCI^[27]。 ABCI介绍^[28]

• 应用层: [Cosmos-SDK (区块链应用开发框架)](https://blog.cosmos.network/hello-world-the-cosmos-sdk-is-ready-for-takeoff-b8857b4057db "Cosmos-SDK (区块链应用开发框架 "Cosmos-SDK (区块链应用开发框架)")")
• Cosmos-SDK Alpha 版本^[29]
• Tendermint ABCI^[30]

正在进行的研究

目前，我们正在深入研究 BLS 签名^[31]，这可能会导致 Tendermint 块头的大小从 3.2 KB（约 100 个验证器）减少到 64 字节。

我们还设计了一种以安全方式随机化轮询提议者选择功能的设计，以使 DDoS 攻击下一个提议者更加困难，但第一步是哨兵节点架构。

微信外链