原文作者：Tess Rinearson
原文链接：
Tendermint Core 已有近七年历史。如今，它横跨数个重要区块链生态，确保了大量转账的安全，其总金额达数十亿美元。尽管如此，它仍被视为 pre-1.0 软件。
我们正致力于改变这一点。
虽然 pre-1.0 这种编号方式给予了开发团队极大限度的灵活性，但它的弊端也很明显：对用户不利。不仅重大更改不能反应在版本号中， 我们的接口和编码系统也时常发生变动，影响它们所支撑的用户软件。
Tendermint Core 1.0 的首要目标是稳定性。它必须足够可靠，使人们能放心地在其之上搭建软件，投入生产。为此，Tendermint Core 的接口必须更加清晰、恒定。同时，为了给 Tendermint Core 的高效性与准确性奠定信心，我们需要通过代码重组优化性能，并进行更完善的测试。
本文罗列了一些 1.0 版本发布时的必要功能。不过，请留意「1.0」在本文中的特定含义。与人们常规对软件开发的期待有所不同，我们的意图并非是把 Tendermint Core 在 1.0 开发至功能齐全或是彻底「完善」；相反，我们追求的只是纯粹的稳定性而已。
发布 Tendermint Core 1.0 意味着我们将为用户保障更强大的稳定性。达到 1.0 也意味着我们可以更轻易地使用语义化版本控制之类的规范，来表达并维持我们的稳定性标准。
说起对 1.0 的要求，如果归纳下所有新功能和改进，结果会颇似马斯洛需求层级和食物金字塔：工作量最大却最凡常的目标放在底部，而工作量更小却更高光的改进放在顶部。
这些改进很可能会被区分为两组版本发布：0.35 和 1.0。本文的结尾有更多注释，用于解释这可能会如何进行。
同时，在 2021 年 1 月，其中一些项目已着手进行，甚至近乎完成；这些项目在下文中已用星号*标出。
一、接口稳定性
API 稳定性
向 Tendermint Core 的用户做出保证：公开暴露的 API 在未来的子版本中不再会发生变动。一旦我们完成这一目标，我们也将终于拥有符合语义化版本控制的规范！
为此，我们会在 Go、RPC 和 P2P api 中定义专门的公共接口，并且弃用和/或不公开所有其他接口，这可能通过使用内部包来实现。这会让我们在未来有能力继续灵活地调整这些接口，但无需为此发布主版本。
ABCI 更新
Tendermint Core 1.0 需要有一个稳定的 ABCI, 以确保依赖于它的应用不会因为突然的变动受到影响。我们计划与 Sikka 紧密合作，整合他们在 ABCI++ 提案中做出的工作。
为‘privval’准备的 gRPC 接口*
在 Tendermint 与 privval (「私有验证人」本地实现的可执行签名的验证人) 之间的接口应当使用 gRPC.
评估 gRPC，并可能将其用于 RPC layer
从 jsonrpc 到 gRPC，我们已经为 RPC 层探索了许多选项。有不少用户对 gRPC 充满热情，因为它给我们提供了一些「免费」的优秀特性，但它也带来了在复杂性上的取舍并可能需要额外工具。
作为我们向 1.0 推进的一步，我们将确认 gRPC 是否适用于我们的 RPC 层。如果合适，我们会将其实现。这项工作会从 RFC 开始，同时也寻求社区成员和用户更多意见。如果这个 RFC 被接受，我们将为 RPC 层编写一个过渡计划并执行它。
Don’t Panic
Tendermint Core 在目前对其严重错误（Panic）的使用较自由，在最糟的情况下可能会导致节点崩溃。根据童子军规则（Scout coding），我们在尝试用递回调用者的报错（error）代替 Panic；不幸的是，由于函数签名将错误添加为返回参数，Go API 可能会发生变更。
在发布 Tendermint Core 1.0 之前，我们将共同努力，比如进行内部审计，在稳定 API 之前，消除所有遗留的、不当的严重错误。
版本化的技术文档*
不同版本的 Tendermint Core 有不同的 API、规范等文档。我们今年的优先事项之一便是确保文档和规范都有着正确的版本标记，并易于访问。
二、区块协议稳定性
在下一个主要版本（即 2.0）发布之前，1.0 将是最后一次对区块协议做出重大更改的版本。在 1.0 发布之前，我们会仔细评估所有中高优先级的重大更改。
软链升级*
在过去，若一个新版本对区块协议有重大更改，基于 Tendermint 的链必须硬分叉才能升级到该版本。这个过程时常很痛苦：所有节点必须协定一个停止高度/时间，使其中应用程序状态被导出到一个「新」链中。理论上，这意味着网络将经历一个复杂的协调过程，并在新链上丢失过去的交易历史。实际上，这意味着许多网络会为了避免麻烦放弃更新，而长时间用不上新功能。
通过拓宽依靠软分叉所能完成的变更类型，Tendermint core 1.0 将减少对这类硬分叉的需求。
版本化的，统一的协议规范*
Go 和 Rust 的实现采用了 Tendermint 技术规范，而有时会有区别。在 Tendermint 1.0 完成前，我们将会有一个连贯、全面、统一和版本化的规范，以匹配基于 Go 的 Tendermint Core 特定版本实现。作为实现的上游依赖，它很可能经历发布（release）过程。
采用 ZIP 215*
不同的 Ed25519 实现验证签名的方式有微妙的不同。对于将来可能使用不同 Ed25519 库的 Tendermint 实现，这会是个问题。来自 Zcash Foundation 团队的 ZIP 215「 可以解决这种情况：它可以明确定义 Ed25519 有效性标准并使其与批量验证兼容。」
在 Tendermint Core 1.0 发布时，它将使用 ed25519-zebra 进行签名验证。
评估基于提议者的 BFT 时间戳，并可能进行实现
Tendermint 在时间戳方面有悠久的历史。最初，Tendermint 使用基于提议者的非拜占庭通错时间：块未经分辨地使用提议了该块的节点的时间戳。当前，Tendermint 使用中位数的 BFT 时间：块的时间戳是所有投票的验证人提供的时间戳的中值。归根结底，我们怀疑我们想返回基于提议者的时间戳，以在签名聚合和 IBC 安全方面都具有优势。但是这次，我们希望该时间戳是具有拜占庭容错的。
这将是与 Informal Systems 研究团队的合作，作为开始，他们将为基于提议者的 BFT 时间戳提出一个规范更改。
考虑减少验证人地址冗余，并可能进行实现
验证人地址目前被包括在区块的两个地方中：Votes 和 CommitSigs。这是冗余的，且增加了块的大小；但它又对调试有帮助。对于 Tendermint 1.0，我们需要就是否保留此冗余做出最终决定。
评估「立即执行」，并可能进行实现
LazyLedger 的团队指出，Tendermint 的「 延迟执行（delayed execution）」模型既是一次接一个的错误的主要温床，又使某些收费机制难以实施或无法实施。我们想评估过渡到「立即执行（immediate execution）」模型的可能性，其中区块所包含的 AppHash 指向当前状态，而不是最后一个状态。
这种变化将是突破性的，很可能是 LazyLedger 和 Tendermint Core 团队之间的探索性合作。上述 ABCI ++ 提议也可能涵盖类似的优势。
考虑定制化区块头数据，并可能进行实现
LazyLedger 团队还提出了一种在区块头中包含自定义信息的方法。我们认为这也可能对其他团队有用，因此我们将评估向区块头添加新的元数据字段以及添加新的区块预处理阶段来允许应用程序写入该字段的可能性。这几乎肯定会与 ABCI ++ 提案重叠。
三、性能
重新设计和重构内存池
今年初，社区运行了一个名为 Game of Zones 的激励性测试网。这很好地揭示了基于 Tendermint 的网络在扩大规模时会遇到的各种性能需求。我们还了解到，如果将当前的 Tendermint 内存池置于这种负载之下，它将压力巨大。
随着各种基于 Tendermint 的网络的发展，我们将需要一个更精密的内存池，可以减少负载并提升交易优先级。我们还将寻求用户的反馈，以确保新的内存池可以支持更广泛，更复杂的应用需求。
请注意，我们已经讨论了创建「可插拔」内存池的可能性，并且我们决定不将其包含在 Tendermint Core 1.0 的规划中：在更稳定的 1.0 版推出后，我们会对必需的公共接口更加有信心。
保留顺序的数据库密钥*
块存储使用字母顺序排列，这使得无法进行有效的范围扫描。我们需要将此编码更改为使用数字顺序的编码。
基准，可扩展性和性能评估
如果从未测量，性能真的提高了吗？
为了有效提高性能，我们需要在网络扩展大量交易，区块和验证人的同时，更积极地跟踪和测试我们的绩效。这将有助于我们对 Tendermint Core 中的瓶颈建立认识，并防止性能在以后的 Tendermint 版本中下降。我们还将与高负载网络积极合作，以确保我们的软件可以处理其负载。
四、正确性
端到端测试*
我们希望有一个端到端的测试套件，可以针对各种配置排列运行一组测试——配置和创世参数的排列、网络拓扑、拜占庭行为和混沌测试，每天晚上自动针对 master 运行
超前测试方案*
我们希望利用分布式系统测试和验证方面的最新进展，使用这些工具使我们对 Tendermint 实现的正确性具有更多信心。我们还想开始利用 Informal Systems 团队已完成的在正式验证、一致性测试和基于模型的测试等方面的工作。最终，我们的超前测试会采取基于模型的测试、Jepsen 测试、Elle 测试、Twins 测试，或上述的某些组合的形式。
五、安全性
证据处理跟进
Tendermint v0.34 引入了一种处理证据的新方法。作为这个版本的后续，我们希望「强化」证据流，比如为证据增加端到端测试和单元测试。几乎肯定的是，我们还会与 Informal Systems 的研究团队一起进行审计，类似于对 IBC 进行的审计。
此外，我们还想更仔细地研究 amnesia 证据：我们在发布新的轻客户端时没有自动处理轻客户端的 amnesia 证据。也就是说，虽然轻客户端可以识别并记录 amnesia 攻击的企图，但这些证据实际上并不能识别具体的始作俑者（们）。即将发布的版本将更仔细地检查这些攻击，并找到一种方法来将足够的信息传递给应用，这样它们就可以遵循某些协议，让行为不端的节点对 amnesia 攻击负责。
跨升级的问责
在进行链升级时，来自旧链的证据应该被保留，这样可以保证节点能对升级前的不当行为负责。我们将首先评估当前问责制的局限性，与 IBC 团队一起理解跨链影响，并编写和分发 RFC。
点对点重构
最近在点对点（P2P）层中出现了许多关于 vector 的安全问题。长期以来，重构 P2P 层一直是「愿望清单」中的一项：各种 P2P 组件的高度纠缠性使得它们很难被分析或安全地更改，而这些安全问题有助于为解决这一问题提供更多的紧迫感。
我们的目标是一个更简单的 P2P 层，使其具有更直接的架构，可以更容易地修补，并且具有更少的 DOS vector 和其他安全漏洞。
在 1.0 版中，这个重构被谨慎地分配到了内部改进和新的传输支持；我们不打算在 1.0 之前进行破坏性的协议更改，更不会在基础变更完成之前进行。
六、可用性改进
尽管前面提到的许多项目都可以改善用户体验，但我们也在考虑一些额外的功能用于针对性地增进可用性。
轻客户端的可用性提升
启动新的轻客户端并非那么容易：用户必须找到见证人的 P2P 终端和节点 IP 地址以及受信任的包头，才能启动新的轻客户端。我们计划以信任最小化（即去中心化）的方式帮助人们做到这一点。
尽管这些功能尚未完全完成设计或确定范围，但我们确定我们想使启动新的轻客户端变得异常容易，这对于 Tendermint Core 1.0 至关重要。
区块链反应器清理
我们目前有三个版本的区块链反应器（Reactor v0, v1, v2），所有这些都负责获取和应用区块。对于不确定应当使用什么版本的用户来说，这很令人疑惑。我们希望让所有人最终都使用一个版本。这个版本很可能是 v2，因为它已经完成设计并被正式验证。最后，我们希望有一个单独的、经过良好测试的、可正式验证的反应器来执行区块链反应器的功能。也许它甚至会有一个比「区块链」更直观的名字!
附录
发布计划
一个单独的版本很可能远不够承载本文罗列的所有内容；因此，我们设想如下的分批发布。请注意，较大的软件功能本身就被分割到了不同的版本中，一般根据计划/设计的阶段（用于做出决定）和实现阶段区分。
第一次发布（0.35）
- 有版本的标准
- 有版本的文档
- 有文档的协议与数据类型
- 关于 API 稳定性和 ABCI 升级的大纲文档
- 为提出的 ABCI 升级所写的 RFC
- 用于 privval 的 gRPC 接口
- 决定（RFC 和 ADR）是否将 gRPC 用于实现我们的 RPC 层
- 软升级计划
- 证据处理的跟进
- 端到端测试
- 评估「立即执行」
- 评估定制化区块头信息
- 高端测试技巧
- P2P 重构设计阶段一
- 弃用 v0 和 v1 的区块链反应堆（把 v2 作为默认）
第二次发布（1.0）
- 基于提议者的时间戳
- 内存池重新设计与重构
- 缩减验证人地址冗余
- 稳定化的 API（Go，P2P，RPC）
- ABCI++/稳定的 ABCI
- 消除严重错误
- 改进轻客户端可用性
- gRPC 层实现（从 0.3 5版的决定进行跟进）
- P2P 重构（从 0.35 版写完的设计进行跟进）
- 移除区块链反应堆 v0 和 v1
排除的功能
一个好的计划不仅需列清什么是需要做的，而且应当明确什么不要做。从这个角度来说，我们决定推迟或忽略如下功能：
- 重构共识反应堆，延期
- 签名聚合，延期
- 数据存储改进，延期
- 投票提案签署后续行动，延期
- Canary 测试，延期
- 随机化提议者选择，延期
- 自定义索引器，排除
- 验证人密钥轮替，排除，并可在应用层被处理
您可以通过以下方式找到 Cosmos：
论坛：https://forum.cosmos.network
微信公众号：cosmosnetwork
加微信群：irisnetwork2018 (或扫描下方图片二维码)
英文电报群：Telegram: Contact @cosmosproject
推特（中文）：https://twitter.com/cosmoschina
推特（英文）：https://twitter.com/cosmos
Medium：https://blog.cosmos.network
币乎：Cosmos