关于11月比特币现金将添加CTOR事件
新的交易排序规则（“CTOR”）是2018年11月比特币现金协议升级的计划变更之一。 比特币现金社区已就这一变化进行了相当多的讨论。
我之前发表过一篇文章，简单地解释了这一变化是什么。
虽然那篇文章让一些读者感到满意并且说服他们认为CTOR并不危险，但其他人仍然表示怀疑，他们想知道这种改变是否必要。
许多人心中的问题是：“为什么我们需要CTOR？ 我们为什么现在需要它？ 还有其他殊路同归的做法吗？”
我想在这里回答这些问题。
CTOR是全面技术路线图的其中一环，旨在帮助比特币现金成为全球的点对点电子现金。
更具体地说，CTOR最明显的主要优点就是更快的区块传送，当然还有一些额外的好处。
遗憾的是，关于CTOR的许多技术讨论都是在区块验证而不是区块传送，这给整个讨论带来了相当大的复杂性和混乱度。
梳理4种不同的交易排序方案
首先，让我们通过研究比特币现金交易排序的4种不同方式来开展分析。
- TTOR - 拓扑交易排序规则
这是比特币现金的当前共识规则。 交易有部分排序规则。 它们可以是任何顺序，但必须强制执行将母交易排列在子交易之前的拓扑。
- ATOR - 任何交易排序规则
此排序将取消当前的TTOR规则，允许任何交易顺序。 这个想法已被讨论认为是CTOR的替代方案和前身。
- GTOR – 加文交易排序规则
这是由加文•安德烈森(Gavin Andresen)在2014年4月提出的。它本质上是一个规范的交易排序，但排序不是强制性的（非共识），它也保留了当前的TTOR规则。
- 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》