BCH擴容的摩爾定律——為什么BCH目前不選擇分片？區塊鏈
如果我們希望比特幣現金可以根據摩爾定律進行擴容，那么可能不會選擇分片。
通常情況下，摩爾定律是適用于比特幣現金擴容的，作為比特幣現金如何隨著未來使用量的增加而擴容的論據。的確，過去晶體管的數量變化符合摩爾定律。但是，值得注意的是，當前單核的時鐘頻率（主頻，指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中，從而讓礦工可以在全局范圍內收取費用，因為必須要維持比特幣現金的激勵。
1.TMT觀察網遵循行業規范，任何轉載的稿件都會明確標注作者和來源；
2.TMT觀察網的原創文章，請轉載時務必注明文章作者和"來源：TMT觀察網"，不尊重原創的行為TMT觀察網或將追究責任；
3.作者投稿可能會經TMT觀察網編輯修改或補充。
