比特币规范交易排序提议的评估

本文是对规范交易排序提议（CTOR）的评估，该提议旨在改变比特币现金（BCH）网络中块内交易的排序。 （nChain 认为 BCH 是真正的比特币。）在总结提议后，我们根据常规变更管理标准评估了提议的变更。

由于下列讨论的原因，我们认为没有足够的证据表明 CTOR 提议将实际提供其声称的益处，并且实现这种有争议的共识变更的风险超过任何未经证实的回报。因此，我们认为 CTOR 提议不应在任何比特币现金实现中实施。

1. CTOR 提议

目前，BCH 块内的交易排序是一种松散的部分排序形式：

• 第一笔交易是 Coinbase 交易；

• 如果交易在同一区块中花费另一笔交易的产出，则支出交易必须在交易所花费的交易之后；

• 所有其他交易–即花费先前区块交易所获产出的交易 - 可以按任何顺序出现。

这被称为交易拓扑排序（TTOR）。

规范交易排序提议（CTOR）旨在根据如下方式改变区块内交易的排序：

• 第一笔交易是 Coinbase 交易；

• 所有其他交易按交易 ID 字母顺序排序。

CTOR 提议声称跟 TTOR 相比有多项优势，即：

• 消除一类可扩展性的挑战

• 紧凑型包含/排除证明

• 选择加入交易的本地化

• 块发射和传播的效率提高

• 软件实现简化

• 潜在攻击媒介的缓解

在后续文章中，其声称 CTOR 是分割比特币的先决条件，它本身被定位为 CPU 开发从单核性能提升到多核产品的转变之后的下一步。

2. 社区反应

CTOR 引发了比特币社区内部的争论，激烈地提出了赞成和反对它的各种意见。下面总结了这些意见，这也明显表明 CTOR 面临着重大的反对意见，或者至少说，面临着关于是否应该实现的严重问题。

• 在私人 vs 去信任分片中，Tom Zander（Flowee the Hub 创始人）反对 CTOR 作为分片的先决条件，并指出可以在不影响共识规则的情况下实现分片。

• Rawpool BCH 实验室制作了一份技术报告（官方英文翻译，社区提供的英文翻译），其中指出当前的 TTOR 实现已经有多年的发展和渐进式改进，但在成熟的CTOR 实现完成之前保留进一步的判断。

• Jonathan Toomim 发表了规范交易排序，或：我是如何学会停止担心并开始喜欢 DAG 的，他在其中提到，在构建块时，父子支付方案结构是一项重要的成本，并且 Graphene 的效率可以比没有排序时高 7 倍以上。他提出 CTOR 允许简化代码，最后得出结论认为 CTOR 不是并行验证的先决条件。

• /u/awemany （Bitcoin Unlimited 成员）， 引用了 Tom Zander 和其他人的看法，批评了 CTOR 提议，认为 CTOR 解决方案的许多动机和论点在审查时都无效。

• /u/Chris_Pacia （OpenBazaar 开发人员） 对/u/awemany 先前的意见提出了批评，该批评重申了 CTOR 的动机，不同意在没有它的情况下可以实现并行，并且主要通过引入 CTOR 作为次要问题部分地将争论重新围绕着消除 TTOR 进行。

• /u/markblundeberg （Simple Ledger Protoco 合著者） 分析了比特币 ABC 版本0.17.1 和 0.18.1 之间的代码变化。他： （i） 指出，用于验证 CTOR 块的并行算法（称为 Out-Then-In 或 OTI）与现有的 TTOR 同样有效（假设在内部数据结构中进行一次交易序数的一次性非共识变化）；（ii） 观察到根据 GavinAndresen 的建议，可以遵循当前的共识规则实现 Graphene； 且（iii） 得出了一些结论，包括 CTOR 建议中最具破坏性的部分是删除了 TTOR，而且 CTOR 不会为块验证提供任何短期好处，且其长期效益尚未确定。

• 在一对论坛帖子中，Steve Shadders（nChain 开发人员和比特币 SV 技术总监 ）比较了在将交易插入到 Merkle 树中时 Merkle 根重新计算的成本（根据CTOR 的要求）与根据当前优化将交易追加到最后的成本，表明需要对比特币进行更大的内部更改，即用 Merklix 树替换 Merkle 树结构。

• Andrew Stone （Bitcoin Unlimited 主开发人员） 发表了为什么 ABC 的 CTOR 无法扩展化，他认为 CTOR 后的分片提议既不需要 CTOR 也不能解决激励性的可扩展化问题，而且 Graphene 可以在当前的共识规则下进行，使得 CTOR 对于网络优化来说不那么必要。

3. 评估 CTOR 提议

任何改变现有系统的提议都应根据多项标准进行评估，包括：

• 范围

• 风险

• 回报

• 实现成本

• 投入市场时间

• 维护影响

o 技术资源的可用性

o 外部 SLA 管理

• 技术依赖性

• 非功能性需求影响

其中每一项都将以比特币特定和更广泛的通用 IT 系统角度进行评估。

3.1范围

3.1.1代码更改的规模

CTOR 提议的范围大小在于实现它所需的代码更改范围。这是对 bitcoin daemon 的内部更改。这项工作已在比特币 ABC 0.18.1 中完成。

3.1.2基础设施要求

目前不需要额外的基础设施。

3.1.3对上下游系统的影响

CTOR 是对共识的更改。为了避免链分割（无论出于什么意图），在比特币现金网络上运行的每个完全验证的节点实现必须实施一系列兼容的更改。

使用 getblocktemplate 结果的采矿池软件应该不受影响，但是任何自己根据返回数据构建块的软件都必须了解 CTOR 规则。

这不会直接影响 SPV 网络客户端。

3.1.4操作程序

使用 CTOR 操作节点无需其他程序。

3.1.5支持流程

需要对支持流程进行最小的更改。在确定任何被拒绝或孤立的块的根本原因时，团队必须了解新规则。

3.1.6用户培训

比特币现金网络的用户不应该知道 CTOR 的任何变化。但是，在链分割的情况下，用户可以观察他们的交易（无论这些交易是已确认还是未确认），这取决于他们的 SPV 客户端采样的节点以及竞争块是否都包括了他们的交易。

3.2 风险

CTOR 提议改变了当前的共识规则。任何共识规则的更改都要求使用同时激活的一组一致更改来修改所有完全验证的节点实现。这意味着更改或弃用每个节点中的代码，这些节点的行为当前在这些实现中是一致的。

即使有足够的测试，甚至在 testnet 上的多个实现产生了足够的证据，更改也可能会引入一些根本不明显的细微错误。仅在重要用途之后显示的极端情况可能会出现，其结果的严重性可能不尽相同，包括无意的链分裂。但这不是没有先例。

正如前面的“社区反应”部分所指出的那样，人们对 CTOR 提议提出了重大的反对意见，或者至少提出了一些严肃的问题。值得注意的是，Bitcoin Unlimited 成员以压倒多数投票反对 CTOR 提议（22 票反对; 5 票赞成; 3 票弃权）。比特币 SV 实现将不具备 CTOR 功能。

实现共识变更是有风险的，但在社区内存在显著意见分歧时实现共识变更更是如此。因此，对 CTOR 提案的风险评估很高。

3.3 回报

为了评估 CTOR 提议的潜在回报（或其益处或由其提供的价值），我们考虑了上述CTOR 的动机，并评估 CTOR 是否可能实现这些假设的目标。

3.3.1消除一类可扩展性挑战

在 CTOR 提议及其后续文章提出分片策略的背景下，可扩展性似乎指的是扩展计算资源的能力。可扩展性还可以指容量或抗逆性的扩展。然而，由于这些都没有得到讨论，因此将在可扩展算力的背景下评估该声明。

CTOR 提议将相当大的部分专门用于将随机排序的项目排列成拓扑排序所需的计算资源，同时提供离线和在线的现有技术。为了对区块内的交易进行分类，CTOR 是 TTOR的一种计算效率更高的替代方案。

CTOR 提议未能承认的是，交易是通过 P2P 网络接收的，并以拓扑顺序接受进入mempool；任何没有花费 UTXO 集合成员的交易（通过不存在或通过双重支出）不会被允许进入 mempool。简单地按照接收顺序维护有效交易列表（或不论底层存储布局如何维护按顺序排列的交易 ID 列表，或者在接收时分配序号）可确保它们可以在块内呈现，而无需任何计算资源来应用拓扑排序。

将给定的非拓扑排序的要求放置在块内的交易上引发了对额外计算的需要。这可以使用插入排序提前完成，或者可以在从底层存储检索交易时对交易进行重新排序。后续分片文章引用了一个 Merklix 树，这是一种在项目插入时自然进行排序的数据结构。

现有的 TTOR 兼容代码随着时间的推移已得到逐步优化。将交易添加到支持 Merkle 树列表不需要对整个树进行重新计算；随着交易的添加和树的变高，应用了优化来促进树的增长并将现有根转换为内部节点。插入到 Merklix 树中提供了合理的排序，但引入了需要 Merkle 根完全重新计算的可能性（碰巧排序为 Merkle 等同结构的附加交易可能会以同样方式被优化）。

虽然进行扩展以增加处理的交易量的目标是令人满意的，但 CTOR 提议没有提供具体证据表明 CTOR 现在降低了计算资源的利用率，也没有证明扩展的明显收益。此外，CTOR提议的作者没有根据 TTOR 和 CTOR 节点策略的比较提供任何测试指标或仪表数据。也没有关于未来的扩展只能通过共识变化来实现的任何结论性的论据。

3.3.2紧凑型包含/排除证明

CTOR 提议声称可以提供紧凑型包含和排除证明这一项好处。虽然紧凑型证明对于 SPV客户端用例来说当然是非常理想的，但并没有给出明确的解释。

其对于如何生成排除证明也没有提供任何解释。

Merkle 证明

对紧凑型证明的一种可能的解释是 Merkle 证明以某种方式被压缩。

从 CTOR 提议中可以明显看出其对 Merkle 包含证明的紧凑性没有影响。

我们有理由看到共享一个父节点（因此共同的 Merkle 证明直到最终的叶子节点）的两个叶子节点（图中的 TX A 和 TX C）如何不能在它们之间以词序方式包含交易（图中的 TX B）。根据 CTOR 规则，交易应按交易 ID 顺序列出，因此交易不包括在内：

如果查询的交易 TXB 落在具有不同父节点 inode 3 和 inode 4 的两个叶节点 TXA 和TXC 之间，则很难马上清楚地了解证明的保持方式，因为它们不会再在其 Merkle 证明中共享公共路径：

即使假设在具有不同父节点的连续叶节点之间可能存在排除证明，排除证明也绑定到了单个块的范围。为了证明排除整个块链，必须为链中的每个块生成证明。

鉴于无法使用此方法为迄今为止开采的任何块生成排除证明，因此无法生成全链排除证明。

其没有提出排除证明的用例，也没有得出它们是由 CTOR 启用的结论。没有提供包含证明紧凑性的实证。

范围限制

在一篇题为关于令牌协议的紧凑证明的帖子中，Joannes Vermorel（CTOR 提案合著者）提出了紧凑令牌证明的概念。在提及紧凑的包含/排除证明时，CTOR 提议指的可能是这篇文章。

该文讨论了轻量级客户端可能仅下载一些块数据的两种方式。第一种是请求 ID 在给定范围内的所有交易。这种想法的扩展是通过使用类似于虚荣地址挖矿的过程，应用程序用户可以特意针对给定的哈希范围来确保某种类型的所有交易（在引用的文章中，指令牌交易）都属于这类。文章中接着提到，这将允许轻客户端按交易 ID 范围请求块的子集，并且仅有 CTOR 能实现这一点。

虽然我们与 Joannes Vermorel 合作开展了一个项目，但我们相信他的上述论点肯定是错误的。

• 无法保证交易的提交者将首先在目标范围内按虚荣地址挖掘交易 ID。

• 没有任何机制可以阻止另一方采用相同的范围进行虚荣地址挖矿，从而降低了该计划的有效性。

• 建议这种虚荣地址挖矿过程和随后的基于范围的交易查询只有在启用 CTOR 时才能实现，以在根本上不分离 IT 系统的职责。如果希望按哈希 ID 范围提供数据查询，则应配置基础数据存储以支持此类查询，或者如果不能实现，则应将数据存储迁移到可以实现的方案。应提供此类查询模式的 RPC 端点。数据存储/检索和轻量级客户端端点服务是两个独立的职责，应该分别处理。将块传播问题与第三种谨慎责任混为一谈是一种糟糕的工程实践 。

第二种建议方式，即轻量级客户端可以仅下载所有块数据的子集的方式，是指客户端仅每过 n 个块进行下载，对于 n 的某些定义，意味着客户端将仅下载每 n 个块中的 1块以找到相关交易。该建议承认由提交者确定交易将被开采的区块高度的不切实际性，因此这里不再进一步讨论。

3.3.3选择加入交易的本地化

交易本地化是第一方重复管理交易（通过任何方法，例如重新生成签名）直到交易 ID在交易创建者可接受的范围内的过程。它然后会被提交给网络，并且将根据 CTOR 接近于其他管理的交易以符合同一 ID 范围。

CTOR 提议表明这个目标没有益处，尽管如上一节所述，范围受限的轻量级客户端查询可能是潜在的驱动因素。

后续分片提议建议使用交易 ID 作为分区键来进行分片处理过程。如果交易本地化建议的意图是允许那些向网络提交交易的人试图以给定的分片为目标，那么这是一个有缺陷甚至可能是危险的建议。

这无法保证给定节点将会运行特定数量的分片，因此无法保证这将确保本地化交易将会位于特定分片上。此用例也没有明确的益处。最后，攻击者可以通过生成具有窄范围标识符的交易来使用此行为，使得一个分片超载。这是一种与后续分片提议特定相关的拒绝服务攻击形式。

3.3.4块发射和传播的效率提高

CTOR 提议（错误地）指出，CTOR 将数据模型从列表转移到一组交易。这是不正确的，因为块中的交易已经是一个集合。列表和集合的唯一不同在于，集合中所有元素都是唯一的。假设这只是一个错误并且 CTOR 提议的意图是强调模型从一个集合转变为一个有序集合，CTOR 提案指出这一变化允许应用易于理解的集合协调技术来减少块发射和

传播期间传输的数据量。

该领域的现有工作，例如 Graphene，证明了这种技术。Graphene 不需要任何特定的排序，不过发送者和接收者之间的排序是稳定的。 Bitcoin Unlimited 有一项实现通过包括排序信息和 IBLT 数据，实现 Graphene 的大部分优势，而无需改变公式规则，Bitcoin ABC 的 Amaury Sechet 观察到，在最近（2018 年 9 月 1 日）的 BCH 网络压力测试中，“graphene 块的平均尺寸为 43kb。编码排序 37kb，或占数据的 86%”。

确实，使用 CTOR 可以省略排序信息，只在有效载荷中留下基础集合协调数据。然而，与已经优化较为完善的线路（BU 的实现）相比，这只是一个微小的改进；CTOR 对Graphene 和类似块传播技术的益处很小。

3.3.5软件实现优化

软件越复杂，以下方面难度越大：

• 验证

• 维护

• 推论

• 提升新开发者技能

• 发现错误

因此，降低软件实现的复杂性是一项合理目标。

CTOR 提议讨论了将交易验证代码从当前的一次通过算法更改为两次通过 Out-Then-In（OTI）算法。两者都比较容易理解，因此虽然不是更复杂，但肯定不会太简单。

值得商榷的是，跨线程、进程甚至机器扩展的节点的任何实现是否都不再需要拓扑顺序，并且在这种情况下，CTOR 可能会减少工作负载。但是，鉴于在跨机器共享工作时追踪 TTOR 的排序是微不足道的，简化情况尚未得到证实。

在目前的形式中，CTOR 没有实现这一目标。相反，它会向代码库中添加其他行为。在分析比特币 ABC 0.17.1 和 0.18.1 之间的所有变化时，很难看出复杂性方面有任何重大变化。

3.3.6潜在攻击媒介的缓解

CTOR 提议包含一个附录，其中说明了 CTOR 比 TTOR 更容易实现，来处理重大块（超过10GB）。附录的理论认为，这种简单性表明未来攻击媒介的潜力较低。

这种说法既没有充分的推理支持，也没有证据支持。

3.4 实现成本和投入市场时间

初看起来，CTOR 可能不是一个重大变化，因为本身进行更改的开发成本并不大。但是，测试每个节点实现是否使更改与其他所有实现互相兼容的成本要高得多。两者都没有明确量化。

由于变化本身很小，交付时间很短。然而，由于变化的性质，上市时间应该得到延长。作为一项共识变化，BCH 开发社区应该花费足够的时间在兼容测试节点上。

这还没有开始，因为节点实现类接口仍然存在争议，一些团队根本没有实现 CTOR 提议。

3.5 维护影响

在维护方面，没有发现影响。代码更改很小，很容易理解。在此更改后，无需其他技能即可继续使用代码库。

3.6 技术依赖性

CTOR 提案没有引入额外的技术依赖性。

CTOR 提议的定位是对未来价值交付的依赖，主要是作为扩大规模处理增加的交易量的先决条件，并且最终的块大小比我们今天看到的要大许多个数量级。

目前尚未充分证明 CTOR 对于实现未来的扩展是必要的。

3. 7 非功能性需求影响

实现 CTOR 提议所需的代码更改在概念上很小，理论影响可以忽略不计 - 即既不显著积极也不消极。

没有发布非功能性测试的结果来支持这一点。

4 评估摘要

虽然一些 CTOR 提议的目标乍一看似乎很了不起，但没有充分证明这些目标实际上是通过实施 CTOR 实现的。此外，作为一项共识变化（且具有高度争议），实现 CTOR 存在重大的相关风险，且没有证明其益处。出于这些原因，nChain 认为不应该实现 CTOR提议。