原文题目：《Tendermint: Byzantine Fault Tolerance in the Age of Blockchains》
原文作者：Ethan Buchman
翻译：傅晓波
校对：潘振东
本文为节选
目前为止的章节，论文阐述了Tendermint共识协议和应用环境相关的基础要素。现实世界中系统的关键要素，例如验证人集合（validator set）的变更管理、故障恢复机制等，还尚未讨论。
这个章节提出了一种解决这些问题的方法，正视共识系统的治理任务。当验证人集合包含更分散的代理人集合时，维护网络的有效治理将变得非常重要。
Governmint
治理（governance）的基本职能是筛选提议行为，通常是以一种投票的形式来完成的。治理的实现作为软件的最基础模块，它允许用户发起提议，对其进行投票，并对投票进行计数。提议可能是程序化的，在这种情况下，它们可能在成功的投票后进行自动执行；亦或并非程序化的，这种情况下它们的执行依赖于手工运行。
为了在Tendermint中启用特定的操作，比如验证人集合变更、升级软件，而实现了一个叫Governmint的治理模块。Governmint是一个最小的、可行的治理应用程序，它支持多组实体，每一个都是可以内部投票的提议，其中一些可能产生程序化执行的行为，就像验证人集合变更，或Governmint的自动升级等。
系统利用数字签名对投票验证人进行身份验证，并可能使用各种可能的投票方案。特别有趣的是二次投票方案，投票的成本是投票权重的二次方。这点被证明了更加能满足投票验证人的选择权。
验证人集合变更
验证人集合的变更是现实世界共识算法的一个重要组成部分，许多以前的方法论都没有这方面的说明，也或许像某种魔法（black art）一样失传了。Raft算法为验证人集合变更阐述了一个健全的协议，这需要使用一个新的消息类型，使更改通过协商一致。Tendermint采用了类似的方法，不过它是通过使用EndBlock消息的TMSP接口标准化的，该消息在所有AppendTx消息之后运行，但在提交之前。如果一个交易或一组交易包含在一个块中，其目的是更新验证人集合，那么应用程序可以通过指定它们的公钥和响应EndBlock消息的新的投票权来返回要更新的验证人列表。验证人可以通过将其投票权重（voting power）设置为零来删除。这为应用程序提供了一种通用的方法来更新验证人集合，而无需指定交易类型。
如果高度为H的区块返回了一组已更新的验证人集合，那么在H+1高度的区块中将反映出这个变更。但是请注意，在H+1这个高度区块的LastCommit方法必须使用高度为H区块的验证人集合，因为它可能包含了已剔除验证人的签名（signatures）。
投票权重的变更应用到H+1高度的区块，如此下一个出块提议人将受到这个更新的影响。尤其是本应是下一个提议者的验证人已被剔除的情况。这里Round-robin算法可以优雅地处理这个问题，简单有序地转移到下一个出块提议人。因为同一个区块在至少三分之二的验证人节点上被复制，同时Round-robin是确定性算法，所以他们都将进行相同的更新，并等待下一个提议人。
惩罚拜占庭验证人
比特币设计中的一个显著的特点是它的激励机制（incentive structure），就目前而言，协议的目标是通过奖励验证者来激励他们正确行事。虽然这在比特币的共识协议背景下是有意义的，但更好的奖惩制度也许需要提供一种健壮性反激励机制（strong dis-incentives），如此对于网络验证人来说利益共享、风险共担，而不是一些温和的机会成本（opportunity cost）。
在Tendermint中的奖惩可以使用一种方法来实现，这就是由Vitalik Buterin以一种名为Proof-of-Stake的协议来提出的。从本质上来说，验证人必须准备一份安全保证金（他们必须持有一定的股份）才能参与到共识中。如果他们被发现有双重签名的提议或投票行为，其他验证人就可以以交易的形式发布这些违规行为的证据，通过剔除违规者，应用程序状态可以使用交易的形式来变更验证人集合，并惩处他的保证金。这就产生了将显性经济成本与拜占庭行为相关联的影响，进而使得诸如贿赂三分之一甚至更多验证人的拜占庭节点（Byzantine）考量自己的违规成本。
请注意，一种共识协议可能会指定更多的可以被惩罚的行为，而不仅仅是双重签名。我们尤其喜欢惩罚任何带有强烈信号的不当行为——典型如 任何上报的状态变更都不是基于其它节点已上报的状态。例如在Tendermint实现版本中，所有的预提交必须带有证明他们的波卡锁，验证人可能因广播不合理的预提交而受到惩罚。但是请注意，我们不能仅仅因为任何的意外行为而严厉惩罚——例如，当一个验证人在不是他的当前回合而发起提议，可能就是一种异步抢占（pre-empt asynchrony）或节点奔溃（crashed nodes）的情况为依据来优化。
软件升级
Governmint也可以在一个去中心化的网络（decentralized network）上以一种自然的方式商议软件升级问题。众所周知，在一个公共网络上的软件升级是一个具有挑战的事情，需要慎重规划去保持因没有第一时间升级的用户的向下兼容性（backwards compatibility），也不能由于软件引入缺陷、移除产品特性、增加复杂度、或者，也许最糟糕的是未经许可而自动升级而让忠实的用户感到不快。
在比特币上升级一个去中心化的共识系统的挑战是显而易见的。以太坊已经完成了一项成功的、非向下兼容的升级，是因为它有强大的领导力和意见统一的社区；而比特币由于带有恶意、分化的社区以及缺乏强大的领导力，尽管大量的软件工程问题暴露，却不能完成一些必须的升级。
由于变更的适用范围不同，区块链的升级通常可分为软分叉（soft forks）和硬分叉（hard forks）。软分叉意味着向下兼容，并使用协议中的自由度，没有升级的用户可能会忽略这一点，但是这可以为已升级的用户提供新的特性。另一方面，硬分叉是不向下兼容的升级，就比特币而言，硬分叉可能会导致安全方面的破坏，而就Tendermint而言，则会导致整个系统停止运行。
为了应对这一问题，比特币软件的开发者们推出了一系列软分叉，验证人可以通过在新的区块中发出信号来投票。一旦验证人的某个阈值发出更新的信号，它就会自动在整个网络中生效，至少对于支持更新的软件版本的用户来说是这样的。比特币系统的实用性在这些软分叉的基础上得到了极大的提高，而且可以预见这一切将会继续。有趣的是，社区未能对软件成功的硬分叉，一方面引起了人们对该系统长期稳定性的担忧，另一方面也引起了对系统恢复舞弊治理的激励和启发——这是一种无法治理的能力。
考虑到当今世界明显的政府贪腐现象（government corruption），有很多理由采用后一种方法（译者注：去中心化系统治理自治的方案）。如此，由密码学和分布式共识提供了一套新的工具，很大程度上能够实现一定透明度和问责制，这在现代政府的纸质版世界里是无法想象的，甚至在传统网络（traditional web）中的数字世界（digital world）里也不存在，因为传统网络严重缺乏足够健壮的身份验证系统（suffers tremendously from a lack of sufficiently robust authentication systems）。
在使用Governmint的系统中，开发者将是区块链上的可识别个体，可以为系统升级提交提议。这种机制与Github上的Pull Request非常相似，只是它被集成到一个实时运行的系统中，并通过共识协议达成一致。应该使用可配置的更新参数来实现客户端，这样他们就可以指定是系统自动更新还是先通知客户端。
当然，任何未经彻底审查的软件升级对系统来讲都可能形成风险，一般来说应该采取保守的方法来升级。
故障恢复
在某些诸如交易日志中的歧义，或者系统停止运行等紧急事件的情况下，传统的共识系统几乎不提供任何保证，通常需要通过人工干预来解决。
Tendermint确保那些违反安全的验证人可以被标识出来，如此，那些可以连接到至少一个诚实节点的任意客户端，能够明确辨别谁是不诚实的验证人，并由此选择跟随诚实的节点进入一个新的链，其中包含一个不包括拜占庭节点的验证人集合。
例如，假设有三分之一甚至更多的验证人违反了锁定规则（locking rules），导致在高度H提交了两个区块，诚实的验证人可以通过广播（gossipping）所有的投票来确定是谁在重复签名（double-signed）。在这点上，它们不能使用协商一致协议，因为已经违背了基本错误假设。注意，此时能够在高度H搜集投票意味着一种很强的假设场景，在故障期间网络的连通性和可用性，如果p2p网络已经无法提供这个能力，则可能需要验证人使用诸如社交媒体和高可用服务的替代方法来传递凭证（evidence）。只要超过三分之二的诚实节点收集到所有的凭证，就可以启动一条新的区块链。
另一种方法是，修改Tendermint协议来使得预提交（pre-commits）带有波尔卡锁，这能够确保分叉的责任人（those responsible for the fork）会立即受到惩罚，而且不需要额外的公布时间。这项修改有待今后的工作来实现。
Governmint更复杂的应用可能更适合处理各种故障细节，比如永久性崩溃（permanent crash failures）和私钥泄露（compromise of private keys）等。不管怎样必须仔细考虑这些问题，因为它们可能破坏底层协议的安全保障。我们把对于这些问题的研究留给未来的工作，但请注意在理解区块链从故障恢复的能力方面，它所处的社会经济环境的重要性。
无论故障恢复如何进行，能否成功还是取决于客户端集成。如果客户端不接受新链，那么它提供的服务实际上是离线的。因此，客户端必须知道指定区块链用于恢复的具体规则。在上述安全违规的情况下，它们还必须搜集凭证来确定要移除哪个验证人，并通过其余的验证人重新计算状态。在没有在线的情况下，保持治理能力。
最后结论
治理能力是分布式共识系统的一个关键要素（critical element），尽管主流的治理系统仍未得到充分理解。Tendermint提供了一种称为Governmint的TMSP模块，旨在促进对分布式系统的基于软件治理（software-based governance for distributed systems）的更多实验。
相关阅读：
