关于11月比特币现金将添加CTOR事件

​​新的交易排序规则（“CTOR”）是2018年11月比特币现金协议升级的计划变动之一。 比特币现金社区已就这一变化进行了至关多的讨论。

我以前发表过一篇文章，简单地解释了这一变化是什么。

虽然那篇文章让一些读者感到满意而且说服他们认为CTOR并不危险，但其余人仍然表示怀疑，他们想知道这种改变是否必要。

许多人心中的问题是：“为何咱们须要CTOR？ 咱们为何如今须要它？ 还有其余殊路同归的作法吗？”

我想在这里回答这些问题。

CTOR是全面技术路线图的其中一环，旨在帮助比特币现金成为全球的点对点电子现金。

更具体地说，CTOR最明显的主要优势就是更快的区块传送，固然还有一些额外的好处。

遗憾的是，关于CTOR的许多技术讨论都是在区块验证而不是区块传送，这给整个讨论带来了至关大的复杂性和混乱度。

梳理4种不一样的交易排序方案

首先，让咱们经过研究比特币现金交易排序的4种不一样方式来开展分析。

1. TTOR - 拓扑交易排序规则

这是比特币现金的当前共识规则。 交易有部分排序规则。 它们能够是任何顺序，但必须强制执行将母交易排列在子交易以前的拓扑。

2. ATOR - 任何交易排序规则

此排序将取消当前的TTOR规则，容许任何交易顺序。 这个想法已被讨论认为是CTOR的替代方案和前身。

3. GTOR – 加文交易排序规则

这是由加文•安德烈森(Gavin Andresen)在2014年4月提出的。它本质上是一个规范的交易排序，但排序不是强制性的（非共识），它也保留了当前的TTOR规则。

4. CTOR -交易规范排序规则

这就是目前的提议。 “规范”是指仅容许排序的要求。 当前的提议也是“词法”或“词典”，意味着除了coinbase以外的区块中的全部交易都按字典顺序排序。 这在其它讨论中也被称为“LTOR”。

为简便起见，本文此后将使用“CTOR”来指代当前提议（也刚好是LTOR），即便某一特定点更适用于词汇属性。

区块传送

让咱们从头提及。2014年，加文（Gavin）提出了一种区块传送的新方法，他的想法之一就是在区块中采用交易的规范排序。 他的“秘诀”是使用可逆布隆查找表（IBLT）来传达节点mempool中的交易集与对等交易集的差别。

这种思路也就是当前广为人知的Graphene协议的起源。

Gavin最初的排序提议并不属于当前任何一个BCH的实施提议，可是从历史上来看，展现这个想法的起源是相当重要的。现在，对于CTOR来讲，最明显的应用是它有助于Graphene更好地工做。

用一种更直观的方式来解释一下为什么独特的排序有助于区块传送： 若是您只须要传送缺失交易的数据而不是传达区块中交易顺序的信息，就能够节省带宽。 所以，规范排序能够帮助其它区块传送方案，例如Xthin; 所以它的好处不只仅是有助于Graphene。

在已发表的评论中，一名开发人员暗示CTOR对区块传送没有好处，由于矿工能够选择根据当前规则从新排序本身的交易。可是，该评论没有解释这种作法如何提升效率，评论只提供了一个论坛帖子的连接，帖子里说“......其他的交易彻底能够自由从新排序。好比经过txid来实现......”

换句话说，避免规范排序就是为了矿工能够自由选择规范排序？

若是只是为了选择的自由，咱们将在稍后讨论。

一样值得注意的是，发表该评论的人（Awemany）在曼谷矿工会议后改变了他对CTOR的见解……他强调，任何一个提出改变的方法都不值得让比特币分裂。

区块验证

CTOR的一个好处是能够简化区块验证的并行处理。这是取消拓扑排序要求的结果。 可是，并行化不是惟一的好处; 即便在现有的拓扑排序方案下，您仍然能够并行化该过程。

关于区块验证的整个争论其实有点转移注意力（固然多是无心的），由于区块传送是一个比区块验证更大的瓶颈。尽管如此，这可能有助于读者了解关于这一话题的主要论点的前因后果。

最初的交锋是这样的：

CTOR批评者指出（至少在一个理想的实施方案中），节点能够在TTOR下更快地验证交易，由于每一个交易的依赖关系已经被处理。CTOR的支持者则指出，拓扑限制是一个须要验证的额外负担。（换句话说，你不能简单地将区块中的交易划分为并行分区就算完成了。）

而后Jonathan Toomim发布了一个算法，显示如何经过先处理输出，再处理输入（例如“OTI”），使用当前的拓扑排序来完成并行验证。

OTI的方法在TTOR和CTOR中均可以应用。在TTOR的状况下，须要在第一个循环中生成每一个交易的位置图，而且第二个循环确保每一个交易仅花费比其自身更旧的硬币。这里所需的多个循环使得在理想实施状况下实现的TTOR优点变成一个有争议的问题。

总而言之，TTOR和CTOR均可以并行化。初步测试显示二者效率大体相同。但重申一下，这并无太大相关性，由于CTOR显然有助于区块传送，而这是一个更重要的瓶颈。

CTOR的其它优点

CTOR还有其余一些优点。它能够提高UTXO处理，由于顺序插入能够更有效地使用UTXO缓存的树结构，并能扩展UTXO承诺的可能性。

SPV / Light钱包也可享受交易排除证实的微小优点。CTOR还能够容许路由到分片，与merkle构造和验证保持一致。

但最大的第二个好处是简化了代码。若是容许任何一种交易顺序会使代码更加复杂，由于要支持全部顺序。相比之下，按照交易哈希排序可以让区块每次以相同的方式进行构造，让测试变得更简便。

TTOR vs ATOR vs CTOR

围绕验证问题的一些论据并不是针对CTOR; 他们更是与TTOR与ATOR相关的问题。 换句话说，咱们应该保留拓扑排序要求仍是取消它？

一些专家指出，从根本上说，交易的顺序没有固有的价值。我对此的理解是：虽然拓扑顺序能够处理依赖关系，但最初建立顺序是有成本的。大多数开发人员并不反对消除TTOR。这甚至适用于nChain的主要开发人员。

此外，一旦废除拓扑要求，采用规范排序也只是一个相对较小的变化。这也是CTOR提议的原则之一。在ABC实施中，在ATOR之上添加CTOR只须要增长20行代码而已。

关于“中央计划”的异议

对CTOR的一个反对意见（虽然并不成立）是矿工应该能够自由地采用本身的顺序- 他们应该自由地“竞争”以得到构建区块的最佳方式，若是强制他们采用某种顺序无异于“中央计划”。

我坚决支持各类形式的自由市场。然而，矿工应该在交易排序上竞争的想法与在交易方式、ECDSA曲线参数或任何数量的协议细节竞争同样，都没有任何意义。

协议的某些部分只是基础设施的“管道”。 它甚至可能对系统起副作用，由于全部节点都必须支持低效的排序方案。

关于“优化第一”的异议

某些开发人员（特别是Tom Zander）表示但愿继续使用当前的拓扑排序来优化代码。他们不想升级或修改交易顺序，认为应该探索并穷尽现有方案的可能性。

协议开发不该由于某个开发人员但愿继续在某个路线进行探索而停滞不前。

虽然在当前协议限制内进行优化是一种可能的办法，但它不必定是最好的方法。咱们终将选择一条独特的路径，即便这意味着放弃其余路径。

更重要的是，这种方法优先考虑优化而不是选择正确的数据结构，这与计算机编程中的最佳实践背道而驰。

发展路线图

比特币ABC发布了一个技术路线图，详细说明了咱们如何改进协议并实现比特币现金更好的扩容性、可用性和可扩展性的目标。这是咱们将来全面、务实计划的最佳范例。CTOR在该路线图当中是很小但重要的组成部分。

虽然比特币现金社区比比特币ABC大得多，但应该注意的是，ABC路线图能够与2017年11月伦敦小组会议后发布的各小组路线图内容进行兼容。事实上，在2017年12月nChain的路线图中也出现了彻底相同的规范顺序提议。

一个综合的方法也许是最佳方案

CTOR不该被做为独立的协议变动进行评估，而应做为比特币ABC引领的精心策划的技术方法的一个组成部分。

比特币现金协议扩容的方法不止一种，但采用一种“综合的”、符合逻辑的方法，而不是基于孤立变化和“黑客”修复的方法会更有意义。

例如，咱们可使用GTOR来得到规范排序的一些益处，但在graphene区块重建期间这会须要拓扑排序，这会更加复杂。

咱们也可使用当前的拓扑排序实现OTI算法来处理并行验证，但若是CTOR自己就能实现，并且能提供切实的好处而且简化代码，咱们又何须采用零散的方法呢？

CTOR是一个安全且通过验证的协议变动吗？

正如“ELI5文章”中所解释的那样，不一样的交易顺序并不表明完全的改变。

虽然更多测试和对标会很好，但在开始进一步开发开始以前，必需要有正确的数据结构。对于某些群体来讲，若是花几个月的时间作协议变动，却不能保证之后还能继续存在，这自己是不现实的。

大多数协议更改都存在风险/回报的权衡。我曾看到一个错误的评论，说在部署以前应该在testnet上作3 - 5年的测试验证。 可是，若是为了下降风险而谨慎过头，这不必定是一种稳健的作法。

咱们正在与支付解决方案的竞争对手进行PK，包括传统和其余加密货币，以及与咱们本身PK，以便在区块奖励减半以前增长交易量。咱们须要一些深思熟虑的风险权衡，但与此同时也存在停滞的风险。

CTOR已经在路线图上存在已经将近一年，而且已经进行了多年的讨论。

做为现有系统的挑战者，咱们必须提升一个数量级。咱们必须尽早创建扩容性的技术基础，以便企业和应用程序有信心选择比特币现金做为平台。

最后，咱们从BCH压力测试收集到的数据中发现了确凿证据，证实graphene将从CTOR中获益匪浅。

结论

咱们围绕CTOR提议进行了大量辩论和讨论，也有不少混淆的观点。通过研究，CTOR应该是一个明智的变化，它有明显的优点，并无明显的缺点。它是精心规划的比特币现金路线图的一部分。矿工、开发人员、用户和企业都应该支持将其归入2018年11月的协议升级中。

 

脚注

1.Jonald Fyookball, “An ELI5 on Canonical Transaction Ordering”

2.Mengerian, Bitcoin Forum

3.Bitcoin Unlimited, Bitcoin Cash Development and Testing Accord

4.Gavin Andresen, O(1) Block Propagation

5.Ozisik, Andresen, Bissias, Houmansadr, Levine, “Graphene: A New Protocol for Block Propagation Using Set Reconciliation”

6.u/awemany, “A Opinionated Critique of the Canonical Transaction Ordering for Bitcoin”

7.Tom Zander, Bitcoin Forum

8.u/awemany, r/btc

9.u/jtoomim, r/btc

10.Jonathan Toomim “Canonical block order, or: How I learned to stop worrying and love the DAG”

11.Jtoomim “Use output-then-input block validation before fork (with tests)”

12.u/jtoomin, r/btc

13.Shammah Chancellor, “Sharding Bitcoin Cash”

14.Jason Cox, “Benefits of Canonical Transaction Order”

15.Sergio Demian Lerner, twitter

16.Otaci, Bitcoin Forum

17.Deadalnix, implement canonical transaction ordering

18.Linus Torvald, git mailing list

19.Bitcoin ABC, “The Bitcoin ABC Vision”

20.nChain, Bitcoin Cash Development & Testing Accord

21.Chris Pacia, r/btc

文章由BitcoinCash公众号翻译自《The Case for Adding CTOR To Bitcoin Cash in November》​​​​