本文是對規范交易排序提議（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提議。