Rawpool BCH Lab 出品 2018.09.10
联合译者：Lise，Wendy
Bitcoin ABC开发人员Shammah Chancellor于2018年9月6日发表了一篇题为《Sharding Bitcoin Cash》的文章，Lise和Wendy将这篇文章翻译成了中文，供大家品读。
BCH分片技术
当论述比特币如何根据未来的应用扩大而扩容时，摩尔定律通常作为论据之一。确实，摩尔定律确实对于一些晶体管时代是适用的，但我们也注意到，由于物理上的局限，单核CPU的处理速度并未提升，CPU的厂商反而增加了内核数量用于进行平行运算。
这意味着比特币为了迎合摩尔定律，区块构建和验证必须采用额外的CPU内核。为了将额外的内核有效加以利用，我们必须将数据进行局部化处理，这一组织数据进行局部化处理的流程就是分片技术（sharding）。
但目前比特币所采用的数据结构中，区块头中的Merkle根阻碍了数据被局部化处理。通过规范排序（CTOR）改变Merkle根运算的顺序，才能实现数据的分片化处理。比如区块中有4笔交易，如果我们将交易的哈希值（交易ID）按顺序排列，这一新的Merkle根将按照如下方式计算（TX_A HASH < TX_B HASH，从左至右，以此类推）。值得注意的是，对于Merkle的验证这种新的排序方法与过去的方法一样安全。
如果按照CTOR（交易规范排序）将交易归类，可以采用两个独立的算法来计算子树B和子树C的哈希值，运算结果可以返回聚合器生成子树A，并依次与币基交易哈希值结合，为区块模板生成一个有效的Merkle根。
目前，区块的Merkle根必须按照TTOR（交易拓扑顺序）排列的交易列表运算（正在进行中交易排在已达成交易之后），但分片技术必须根据前后一致的分类对数据进行维护。在分片系统中由于可能的数据局部化而造成的不匹配，以及子树哈希值必须计算的数据集，未经过大量的同步，单个分片就无法预先运算子树哈希值。为了解决这一问题，须组织Merkle 树，使其成为单个分片可以计算的子树哈希值集合，从而进行运算。
哈希值标准化交易排序的另一有用特性是：内存池对交易的接收也可以在多个进程间应用分片技术。这可以通过在多个内存池处理器前面放置多个交易“路由器”来实现。
在这种结构中，路由器1和路由器2可以在同一分类中向以前达成的内存池接受器发送交易。采用类似的方法，内存池接受器可以相互查询，还可以查询UTXO数据库，从而保证母交易存在并可以使用。
随着内存池在多个进程间被分片，API请求处理器可以处理各个Merkle子树的哈希值。如图（1）所示，我们可以向子树B和子树C提出请求，之后不断将它们聚合到Merkle根中。
为了构建以上结构中的节点，区块链中的基本数据结构必须率先就位。在适用于运算Merkle根的分片数据结构建立之前，不能轻易利用分片技术编写软件。标准化交易排序应先于任何此类软件的创建。
这就是ABC目前倡导这些变革的原因所在，我们必须为未来的需求做好准备，这意味着我们现在就要开始着手，打造能够处理极大区块的节点。这项任务可谓任重而道远，要花费数年时间才能完成。
有些人提出让ABC制定行之有效的优化性能标准，正如前面提到的，必须首先编写出相应的软件才能确立这样的标准。由于这一进程要耗时数年，标准不能建立，必须在策划之前就开展真正的工程设计。对于工程设计工作的简述已在前面阐明了。
为了支持协议的顺畅升级，目前版本必须能够产生及验证两种类型的区块，其结果是区块模板的生成变慢，对验证产生一些较小影响。由于在初始的拓扑分类后，需要对交易重新分类，事实上当前的Bitcoin ABC v0.18.0 版本生成区块模板的速度略有下降，这是有意而为之，并且这一问题在CTO之后重构代码并且Merklix树最终被激活后能够得到解决。
如果BCH希望根据摩尔定律可扩容，就不一定非要选择分片技术。但是，单个CPU的速度不会明显变快，单靠专门的硬件无法解决扩容问题，因此协议必须向节点推进能够实现水平扩容的软件，因为垂直扩容对于大小约1GB左右的区块就行不通了。并且，水平扩容是针对比特币一层的，矿工们可以在全球范围内收取交易手续费，比特币的激励机制也必然将会维持下去。
感谢阅读。
网友评论