本文件是对规范交易排序提议（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) 观察到根据Gavin Andresen 的建议，可以遵循当前的共识规则实现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 提议

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

范围
风险
回报
实现成本
投入市场时间
维护影响
- 技术资源的可用性
- 外部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顺序列出，因此交易不包括在内：

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

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

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

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

范围限制

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

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

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

无法保证交易的提交者将首先在目标范围内按虚荣地址挖掘交易ID。
没有任何机制可以阻止另一方采用相同的范围进行虚荣地址挖矿，从而降低了该计划的有效性。
建议这种虚荣地址挖矿过程和随后的基于范围的交易查询只有在启用CTOR时才能实现，以在根本上不分离IT系统的职责。如果希望按哈希ID范围提供数据查询，则应配置基础数据存储以支持此类查询，或者如果不能实现，则应将数据存储迁移到可以实现的方案。应提供此类查询模式的RPC端点。数据存储/检索和轻量级客户端端点服务是两个独立的职责，应该分别处理。将块传播问题与第三种谨慎责任混为一谈是一种糟糕的工程实践。

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

1.1.1 选择加入交易的本地化

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

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

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

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

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

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和类似块传播技术的益处很小。

1.1.3 软件实现优化

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

验证
维护
推论
提升新开发者技能
发现错误

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

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

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

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

1.1.4 潜在攻击媒介的缓解

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

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

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

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

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

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

1.3 维护影响

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

1.4 技术依赖性

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

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

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

1.5 非功能性需求影响

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

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

2 评估摘要

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

Note: Tokens on the Bitcoin Core (segwit) Chain are Referred to as BTC coins. Bitcoin Cash (BCH) is today the only Bitcoin implementation that follows Satoshi Nakamoto’s original whitepaper for Peer to Peer Electronic Cash. Bitcoin BCH is the only major public blockchain that maintains the original vision for Bitcoin as fast, frictionless, electronic cash.

The post 比特币规范交易排序：批判性评估 appeared first on Coingeek.

比特币规范交易排序：批判性评估