BCH扩容的摩尔定律—为什么BCH目前不选择分片？

原文作者为Bitcoin ABC的开发人员Shammah Chancellor

通常情况下，摩尔定律是适用于比特币现金扩容的，作为比特币现金如何随着未来使用量的增加而扩容的论据。的确，过去晶体管的数量变化符合摩尔定律。但是，值得注意的是，当前单核的时钟频率（主频，指CPU的运行速度）没有增加——这是由于物理限制。相反，CPU制造商增加了并行处理的内核数量。

这意味着为了使比特币现金的扩容符合摩尔定律，区块构造和验证必须使用额外的CPU内核。为了有效地使用额外的内核，CPU内核使用的数据必须是局部处理的。组织数据用于局部处理的过程称为分片。

然而，比特币现金目前使用的数据结构阻止了数据的局部化。通过规范化（canonicalization）来改变哈希树计算的顺序，可以对数据进行分片。对于一个包含通过散列按字典顺序排列的4个交易的区块（其中TX_A HASH <TX_B HASH，从左到右类推），新的哈希树将按如下过程计算。要注意的是，哈希树的重新排序仍然允许梅克尔证明（Merkle proof）具有与原排序时相同的安全性。

图1 哈希树计算

如果我们可以将交易排序到规范交易排序（canonical ordering of transactions）的范围内，我们可以使用两个独立的进程计算子树B和子树C的哈希值。这些计算的结果可以返回到集合器中以产生子树A。而子树A又可以与coinbase hash组合以产生区块模板的有效哈希树。

目前，必须根据按拓扑顺序排列的交易列表来计算区块的哈希树。但是，分片必须基于一致的范围来维护数据。由于数据在分片系统中的可能位置与子树哈希必须要计算的数据集之间不匹配，因此各个分片无法在没有大量同步的情况下预先计算子树哈希。为了解决这个问题，必须要对哈希树进行组织，从而让哈希树能够以多个子树哈希集合的方式进行计算，而子树哈希可以由单个分片计算。

规范化交易顺序的另一个有用属性是，mempool acceptance（接受进入等待确认的交易集合）也可以在多个进程间进行分片。这可以通过在多个mempool处理器前面放置多个交易“路由器”来完成。

在这种架构中，路由器1和路由器2可以在相同的范围内向先前商定的mempool接收器发送交易。使用类似的方法，mempool接受器可以相互查询，也能查询UTXO数据库，以确保父交易（对应子交易，上一级的交易）存在且可用。

图2 mempool acceptance并行构架

随着mempool在多个进程间被分片，API请求处理器可以查询各个哈希子树的哈希值。在图（1）中，我们可以向子树B和子树C发送请求。然后，我们可以继续将它们集合到哈希树中。

为了构建具有上述架构的节点，必须首先在区块链中使用适当的数据结构。在适用于分片的数据结构建立之前，不能轻易编写软件来使用分片。规范化交易排序应在创建任何此类软件之前进行。

这就是Bitcoin ABC当前提倡这些变化的原因。我们必须为未来的需求做好准备，这意味着我们需要开始工作，让节点能够很好地处理极大的区块——这不是一项容易的任务，需要数年时间才能完成。

有些人要求ABC制定这种优化如何运行的性能基准。如上所述，这样的基准是不可能制定的，因为必须先有分片的软件（现在没有）。由于这将花费多年时间，因此无法制定基准——必须事先进行真正的工程设计才能进行规划。工程工作的概况已经在上文给出。

为了支持平滑的协议升级，当前版本必须能够产生和验证两种类型的区块——结果则是区块模板的生成更慢，对验证产生一些小的影响。实际上，由于需要在初始的拓扑排序后重新对交易排序，因此当前版本的Bitcoin-ABC v0.18.0在创建区块模板时会稍微慢一些。这是有意的，将在CTO之后重构代码并最终能够激活哈希树时解决。

如果我们希望比特币现金可以根据摩尔定律进行扩容，那么可能不会选择分片。单个CPU的速度不会明显加快。专用硬件不能单独解决这个问题。 协议必须便于具备水平扩容能力的节点软件的实施，因为垂直扩容在区块大小超过大约1GB后就行不通了。 而且，改变要发生在比特币现金的lay 1中，从而让矿工可以在全局范围内收取费用，因为必须要维持比特币现金的激励。