本文是對規(guī)范交易排序提議（CTOR）的評估，該提議旨在改變比特幣現(xiàn)金（BCH）網(wǎng)絡中塊內(nèi)交易的排序。 （nChain 認為 BCH 是真正的比特幣。）在總結(jié)提議后，我們根據(jù)常規(guī)變更管理標準評估了提議的變更。

由于下列討論的原因，我們認為沒有足夠的證據(jù)表明 CTOR 提議將實際提供其聲稱的益處，并且實現(xiàn)這種有爭議的共識變更的風險超過任何未經(jīng)證實的回報。因此，我們認為 CTOR 提議不應在任何比特幣現(xiàn)金實現(xiàn)中實施。

1. CTOR 提議

目前，BCH 塊內(nèi)的交易排序是一種松散的部分排序形式：

? 第一筆交易是 Coinbase 交易；

? 如果交易在同一區(qū)塊中花費另一筆交易的產(chǎn)出，則支出交易必須在交易所花費的交易之后；

? 所有其他交易–即花費先前區(qū)塊交易所獲產(chǎn)出的交易 - 可以按任何順序出現(xiàn)。

這被稱為交易拓撲排序（TTOR）。

規(guī)范交易排序提議（CTOR）旨在根據(jù)如下方式改變區(qū)塊內(nèi)交易的排序：

? 第一筆交易是 Coinbase 交易；

? 所有其他交易按交易 ID 字母順序排序。

CTOR 提議聲稱跟 TTOR 相比有多項優(yōu)勢，即：

? 消除一類可擴展性的挑戰(zhàn)

? 緊湊型包含/排除證明

? 選擇加入交易的本地化

? 塊發(fā)射和傳播的效率提高

? 軟件實現(xiàn)簡化

? 潛在攻擊媒介的緩解

在后續(xù)文章中，其聲稱 CTOR 是分割比特幣的先決條件，它本身被定位為 CPU 開發(fā)從單核性能提升到多核產(chǎn)品的轉(zhuǎn)變之后的下一步。

2. 社區(qū)反應

CTOR 引發(fā)了比特幣社區(qū)內(nèi)部的爭論，激烈地提出了贊成和反對它的各種意見。下面總結(jié)了這些意見，這也明顯表明 CTOR 面臨著重大的反對意見，或者至少說，面臨著關(guān)于是否應該實現(xiàn)的嚴重問題。

? 在私人 vs 去信任分片中，Tom Zander（Flowee the Hub 創(chuàng)始人）反對 CTOR 作為分片的先決條件，并指出可以在不影響共識規(guī)則的情況下實現(xiàn)分片。

? Rawpool BCH 實驗室制作了一份技術(shù)報告（官方英文翻譯，社區(qū)提供的英文翻譯），其中指出當前的 TTOR 實現(xiàn)已經(jīng)有多年的發(fā)展和漸進式改進，但在成熟的CTOR 實現(xiàn)完成之前保留進一步的判斷。

? Jonathan Toomim 發(fā)表了規(guī)范交易排序，或：我是如何學會停止擔心并開始喜歡 DAG 的，他在其中提到，在構(gòu)建塊時，父子支付方案結(jié)構(gòu)是一項重要的成本，并且 Graphene 的效率可以比沒有排序時高 7 倍以上。他提出 CTOR 允許簡化代碼，最后得出結(jié)論認為 CTOR 不是并行驗證的先決條件。

? /u/awemany （Bitcoin Unlimited 成員）， 引用了 Tom Zander 和其他人的看法，批評了 CTOR 提議，認為 CTOR 解決方案的許多動機和論點在審查時都無效。

? /u/Chris_Pacia （OpenBazaar 開發(fā)人員） 對/u/awemany 先前的意見提出了批評，該批評重申了 CTOR 的動機，不同意在沒有它的情況下可以實現(xiàn)并行，并且主要通過引入 CTOR 作為次要問題部分地將爭論重新圍繞著消除 TTOR 進行。

? /u/markblundeberg （Simple Ledger Protoco 合著者） 分析了比特幣 ABC 版本0.17.1 和 0.18.1 之間的代碼變化。他： （i） 指出，用于驗證 CTOR 塊的并行算法（稱為 Out-Then-In 或 OTI）與現(xiàn)有的 TTOR 同樣有效（假設在內(nèi)部數(shù)據(jù)結(jié)構(gòu)中進行一次交易序數(shù)的一次性非共識變化）；（ii） 觀察到根據(jù) GavinAndresen 的建議，可以遵循當前的共識規(guī)則實現(xiàn) Graphene； 且（iii） 得出了一些結(jié)論，包括 CTOR 建議中最具破壞性的部分是刪除了 TTOR，而且 CTOR 不會為塊驗證提供任何短期好處，且其長期效益尚未確定。

? 在一對論壇帖子中，Steve Shadders（nChain 開發(fā)人員和比特幣 SV 技術(shù)總監(jiān) ）比較了在將交易插入到 Merkle 樹中時 Merkle 根重新計算的成本（根據(jù)CTOR 的要求）與根據(jù)當前優(yōu)化將交易追加到最后的成本，表明需要對比特幣進行更大的內(nèi)部更改，即用 Merklix 樹替換 Merkle 樹結(jié)構(gòu)。

? Andrew Stone （Bitcoin Unlimited 主開發(fā)人員） 發(fā)表了為什么 ABC 的 CTOR 無法擴展化，他認為 CTOR 后的分片提議既不需要 CTOR 也不能解決激勵性的可擴展化問題，而且 Graphene 可以在當前的共識規(guī)則下進行，使得 CTOR 對于網(wǎng)絡優(yōu)化來說不那么必要。

3. 評估 CTOR 提議

任何改變現(xiàn)有系統(tǒng)的提議都應根據(jù)多項標準進行評估，包括：

? 范圍

? 風險

? 回報

? 實現(xiàn)成本

? 投入市場時間

? 維護影響

o 技術(shù)資源的可用性

o 外部 SLA 管理

? 技術(shù)依賴性

? 非功能性需求影響

其中每一項都將以比特幣特定和更廣泛的通用 IT 系統(tǒng)角度進行評估。

3.1范圍

3.1.1代碼更改的規(guī)模

CTOR 提議的范圍大小在于實現(xiàn)它所需的代碼更改范圍。這是對 bitcoin daemon 的內(nèi)部更改。這項工作已在比特幣 ABC 0.18.1 中完成。

3.1.2基礎(chǔ)設施要求

目前不需要額外的基礎(chǔ)設施。

3.1.3對上下游系統(tǒng)的影響

CTOR 是對共識的更改。為了避免鏈分割（無論出于什么意圖），在比特幣現(xiàn)金網(wǎng)絡上運行的每個完全驗證的節(jié)點實現(xiàn)必須實施一系列兼容的更改。

使用 getblocktemplate 結(jié)果的采礦池軟件應該不受影響，但是任何自己根據(jù)返回數(shù)據(jù)構(gòu)建塊的軟件都必須了解 CTOR 規(guī)則。

這不會直接影響 SPV 網(wǎng)絡客戶端。

3.1.4操作程序

使用 CTOR 操作節(jié)點無需其他程序。

3.1.5支持流程

需要對支持流程進行最小的更改。在確定任何被拒絕或孤立的塊的根本原因時，團隊必須了解新規(guī)則。

3.1.6用戶培訓

比特幣現(xiàn)金網(wǎng)絡的用戶不應該知道 CTOR 的任何變化。但是，在鏈分割的情況下，用戶可以觀察他們的交易（無論這些交易是已確認還是未確認），這取決于他們的 SPV 客戶端采樣的節(jié)點以及競爭塊是否都包括了他們的交易。

3.2 風險

CTOR 提議改變了當前的共識規(guī)則。任何共識規(guī)則的更改都要求使用同時激活的一組一致更改來修改所有完全驗證的節(jié)點實現(xiàn)。這意味著更改或棄用每個節(jié)點中的代碼，這些節(jié)點的行為當前在這些實現(xiàn)中是一致的。

即使有足夠的測試，甚至在 testnet 上的多個實現(xiàn)產(chǎn)生了足夠的證據(jù)，更改也可能會引入一些根本不明顯的細微錯誤。僅在重要用途之后顯示的極端情況可能會出現(xiàn)，其結(jié)果的嚴重性可能不盡相同，包括無意的鏈分裂。但這不是沒有先例。

正如前面的“社區(qū)反應”部分所指出的那樣，人們對 CTOR 提議提出了重大的反對意見，或者至少提出了一些嚴肅的問題。值得注意的是，Bitcoin Unlimited 成員以壓倒多數(shù)投票反對 CTOR 提議（22 票反對; 5 票贊成; 3 票棄權(quán)）。比特幣 SV 實現(xiàn)將不具備 CTOR 功能。

實現(xiàn)共識變更是有風險的，但在社區(qū)內(nèi)存在顯著意見分歧時實現(xiàn)共識變更更是如此。因此，對 CTOR 提案的風險評估很高。

3.3 回報

為了評估 CTOR 提議的潛在回報（或其益處或由其提供的價值），我們考慮了上述CTOR 的動機，并評估 CTOR 是否可能實現(xiàn)這些假設的目標。

3.3.1消除一類可擴展性挑戰(zhàn)

在 CTOR 提議及其后續(xù)文章提出分片策略的背景下，可擴展性似乎指的是擴展計算資源的能力。可擴展性還可以指容量或抗逆性的擴展。然而，由于這些都沒有得到討論，因此將在可擴展算力的背景下評估該聲明。

CTOR 提議將相當大的部分專門用于將隨機排序的項目排列成拓撲排序所需的計算資源，同時提供離線和在線的現(xiàn)有技術(shù)。為了對區(qū)塊內(nèi)的交易進行分類，CTOR 是 TTOR的一種計算效率更高的替代方案。

CTOR 提議未能承認的是，交易是通過 P2P 網(wǎng)絡接收的，并以拓撲順序接受進入mempool；任何沒有花費 UTXO 集合成員的交易（通過不存在或通過雙重支出）不會被允許進入 mempool。簡單地按照接收順序維護有效交易列表（或不論底層存儲布局如何維護按順序排列的交易 ID 列表，或者在接收時分配序號）可確保它們可以在塊內(nèi)呈現(xiàn)，而無需任何計算資源來應用拓撲排序。

將給定的非拓撲排序的要求放置在塊內(nèi)的交易上引發(fā)了對額外計算的需要。這可以使用插入排序提前完成，或者可以在從底層存儲檢索交易時對交易進行重新排序。后續(xù)分片文章引用了一個 Merklix 樹，這是一種在項目插入時自然進行排序的數(shù)據(jù)結(jié)構(gòu)。

現(xiàn)有的 TTOR 兼容代碼隨著時間的推移已得到逐步優(yōu)化。將交易添加到支持 Merkle 樹列表不需要對整個樹進行重新計算；隨著交易的添加和樹的變高，應用了優(yōu)化來促進樹的增長并將現(xiàn)有根轉(zhuǎn)換為內(nèi)部節(jié)點。插入到 Merklix 樹中提供了合理的排序，但引入了需要 Merkle 根完全重新計算的可能性（碰巧排序為 Merkle 等同結(jié)構(gòu)的附加交易可能會以同樣方式被優(yōu)化）。

雖然進行擴展以增加處理的交易量的目標是令人滿意的，但 CTOR 提議沒有提供具體證據(jù)表明 CTOR 現(xiàn)在降低了計算資源的利用率，也沒有證明擴展的明顯收益。此外，CTOR提議的作者沒有根據(jù) TTOR 和 CTOR 節(jié)點策略的比較提供任何測試指標或儀表數(shù)據(jù)。也沒有關(guān)于未來的擴展只能通過共識變化來實現(xiàn)的任何結(jié)論性的論據(jù)。

3.3.2緊湊型包含/排除證明

CTOR 提議聲稱可以提供緊湊型包含和排除證明這一項好處。雖然緊湊型證明對于 SPV客戶端用例來說當然是非常理想的，但并沒有給出明確的解釋。

其對于如何生成排除證明也沒有提供任何解釋。

Merkle 證明

對緊湊型證明的一種可能的解釋是 Merkle 證明以某種方式被壓縮。

從 CTOR 提議中可以明顯看出其對 Merkle 包含證明的緊湊性沒有影響。

我們有理由看到共享一個父節(jié)點（因此共同的 Merkle 證明直到最終的葉子節(jié)點）的兩個葉子節(jié)點（圖中的 TX A 和 TX C）如何不能在它們之間以詞序方式包含交易（圖中的 TX B）。根據(jù) CTOR 規(guī)則，交易應按交易 ID 順序列出，因此交易不包括在內(nèi)：

如果查詢的交易 TXB 落在具有不同父節(jié)點 inode 3 和 inode 4 的兩個葉節(jié)點 TXA 和TXC 之間，則很難馬上清楚地了解證明的保持方式，因為它們不會再在其 Merkle 證明中共享公共路徑：

即使假設在具有不同父節(jié)點的連續(xù)葉節(jié)點之間可能存在排除證明，排除證明也綁定到了單個塊的范圍。為了證明排除整個塊鏈，必須為鏈中的每個塊生成證明。

鑒于無法使用此方法為迄今為止開采的任何塊生成排除證明，因此無法生成全鏈排除證明。

其沒有提出排除證明的用例，也沒有得出它們是由 CTOR 啟用的結(jié)論。沒有提供包含證明緊湊性的實證。

范圍限制

在一篇題為關(guān)于令牌協(xié)議的緊湊證明的帖子中，Joannes Vermorel（CTOR 提案合著者）提出了緊湊令牌證明的概念。在提及緊湊的包含/排除證明時，CTOR 提議指的可能是這篇文章。

該文討論了輕量級客戶端可能僅下載一些塊數(shù)據(jù)的兩種方式。第一種是請求 ID 在給定范圍內(nèi)的所有交易。這種想法的擴展是通過使用類似于虛榮地址挖礦的過程，應用程序用戶可以特意針對給定的哈希范圍來確保某種類型的所有交易（在引用的文章中，指令牌交易）都屬于這類。文章中接著提到，這將允許輕客戶端按交易 ID 范圍請求塊的子集，并且僅有 CTOR 能實現(xiàn)這一點。

雖然我們與 Joannes Vermorel 合作開展了一個項目，但我們相信他的上述論點肯定是錯誤的。

? 無法保證交易的提交者將首先在目標范圍內(nèi)按虛榮地址挖掘交易 ID。

? 沒有任何機制可以阻止另一方采用相同的范圍進行虛榮地址挖礦，從而降低了該計劃的有效性。

? 建議這種虛榮地址挖礦過程和隨后的基于范圍的交易查詢只有在啟用 CTOR 時才能實現(xiàn)，以在根本上不分離 IT 系統(tǒng)的職責。如果希望按哈希 ID 范圍提供數(shù)據(jù)查詢，則應配置基礎(chǔ)數(shù)據(jù)存儲以支持此類查詢，或者如果不能實現(xiàn)，則應將數(shù)據(jù)存儲遷移到可以實現(xiàn)的方案。應提供此類查詢模式的 RPC 端點。數(shù)據(jù)存儲/檢索和輕量級客戶端端點服務是兩個獨立的職責，應該分別處理。將塊傳播問題與第三種謹慎責任混為一談是一種糟糕的工程實踐 。

第二種建議方式，即輕量級客戶端可以僅下載所有塊數(shù)據(jù)的子集的方式，是指客戶端僅每過 n 個塊進行下載，對于 n 的某些定義，意味著客戶端將僅下載每 n 個塊中的 1塊以找到相關(guān)交易。該建議承認由提交者確定交易將被開采的區(qū)塊高度的不切實際性，因此這里不再進一步討論。

3.3.3選擇加入交易的本地化

交易本地化是第一方重復管理交易（通過任何方法，例如重新生成簽名）直到交易 ID在交易創(chuàng)建者可接受的范圍內(nèi)的過程。它然后會被提交給網(wǎng)絡，并且將根據(jù) CTOR 接近于其他管理的交易以符合同一 ID 范圍。

CTOR 提議表明這個目標沒有益處，盡管如上一節(jié)所述，范圍受限的輕量級客戶端查詢可能是潛在的驅(qū)動因素。

后續(xù)分片提議建議使用交易 ID 作為分區(qū)鍵來進行分片處理過程。如果交易本地化建議的意圖是允許那些向網(wǎng)絡提交交易的人試圖以給定的分片為目標，那么這是一個有缺陷甚至可能是危險的建議。

這無法保證給定節(jié)點將會運行特定數(shù)量的分片，因此無法保證這將確保本地化交易將會位于特定分片上。此用例也沒有明確的益處。最后，攻擊者可以通過生成具有窄范圍標識符的交易來使用此行為，使得一個分片超載。這是一種與后續(xù)分片提議特定相關(guān)的拒絕服務攻擊形式。

3.3.4塊發(fā)射和傳播的效率提高

CTOR 提議（錯誤地）指出，CTOR 將數(shù)據(jù)模型從列表轉(zhuǎn)移到一組交易。這是不正確的，因為塊中的交易已經(jīng)是一個集合。列表和集合的唯一不同在于，集合中所有元素都是唯一的。假設這只是一個錯誤并且 CTOR 提議的意圖是強調(diào)模型從一個集合轉(zhuǎn)變?yōu)橐粋€有序集合，CTOR 提案指出這一變化允許應用易于理解的集合協(xié)調(diào)技術(shù)來減少塊發(fā)射和

傳播期間傳輸?shù)臄?shù)據(jù)量。

該領(lǐng)域的現(xiàn)有工作，例如 Graphene，證明了這種技術(shù)。Graphene 不需要任何特定的排序，不過發(fā)送者和接收者之間的排序是穩(wěn)定的。 Bitcoin Unlimited 有一項實現(xiàn)通過包括排序信息和 IBLT 數(shù)據(jù)，實現(xiàn) Graphene 的大部分優(yōu)勢，而無需改變公式規(guī)則，Bitcoin ABC 的 Amaury Sechet 觀察到，在最近（2018 年 9 月 1 日）的 BCH 網(wǎng)絡壓力測試中，“graphene 塊的平均尺寸為 43kb。編碼排序 37kb，或占數(shù)據(jù)的 86%”。

確實，使用 CTOR 可以省略排序信息，只在有效載荷中留下基礎(chǔ)集合協(xié)調(diào)數(shù)據(jù)。然而，與已經(jīng)優(yōu)化較為完善的線路（BU 的實現(xiàn)）相比，這只是一個微小的改進；CTOR 對Graphene 和類似塊傳播技術(shù)的益處很小。

3.3.5軟件實現(xiàn)優(yōu)化

軟件越復雜，以下方面難度越大：

? 驗證

? 維護

? 推論

? 提升新開發(fā)者技能

? 發(fā)現(xiàn)錯誤

因此，降低軟件實現(xiàn)的復雜性是一項合理目標。

CTOR 提議討論了將交易驗證代碼從當前的一次通過算法更改為兩次通過 Out-Then-In（OTI）算法。兩者都比較容易理解，因此雖然不是更復雜，但肯定不會太簡單。

值得商榷的是，跨線程、進程甚至機器擴展的節(jié)點的任何實現(xiàn)是否都不再需要拓撲順序，并且在這種情況下，CTOR 可能會減少工作負載。但是，鑒于在跨機器共享工作時追蹤 TTOR 的排序是微不足道的，簡化情況尚未得到證實。

在目前的形式中，CTOR 沒有實現(xiàn)這一目標。相反，它會向代碼庫中添加其他行為。在分析比特幣 ABC 0.17.1 和 0.18.1 之間的所有變化時，很難看出復雜性方面有任何重大變化。

3.3.6潛在攻擊媒介的緩解

CTOR 提議包含一個附錄，其中說明了 CTOR 比 TTOR 更容易實現(xiàn)，來處理重大塊（超過10GB）。附錄的理論認為，這種簡單性表明未來攻擊媒介的潛力較低。

這種說法既沒有充分的推理支持，也沒有證據(jù)支持。

3.4 實現(xiàn)成本和投入市場時間

初看起來，CTOR 可能不是一個重大變化，因為本身進行更改的開發(fā)成本并不大。但是，測試每個節(jié)點實現(xiàn)是否使更改與其他所有實現(xiàn)互相兼容的成本要高得多。兩者都沒有明確量化。

由于變化本身很小，交付時間很短。然而，由于變化的性質(zhì)，上市時間應該得到延長。作為一項共識變化，BCH 開發(fā)社區(qū)應該花費足夠的時間在兼容測試節(jié)點上。

這還沒有開始，因為節(jié)點實現(xiàn)類接口仍然存在爭議，一些團隊根本沒有實現(xiàn) CTOR 提議。

3.5 維護影響

在維護方面，沒有發(fā)現(xiàn)影響。代碼更改很小，很容易理解。在此更改后，無需其他技能即可繼續(xù)使用代碼庫。

3.6 技術(shù)依賴性

CTOR 提案沒有引入額外的技術(shù)依賴性。

CTOR 提議的定位是對未來價值交付的依賴，主要是作為擴大規(guī)模處理增加的交易量的先決條件，并且最終的塊大小比我們今天看到的要大許多個數(shù)量級。

目前尚未充分證明 CTOR 對于實現(xiàn)未來的擴展是必要的。

3. 7 非功能性需求影響

實現(xiàn) CTOR 提議所需的代碼更改在概念上很小，理論影響可以忽略不計 - 即既不顯著積極也不消極。

沒有發(fā)布非功能性測試的結(jié)果來支持這一點。

4 評估摘要

雖然一些 CTOR 提議的目標乍一看似乎很了不起，但沒有充分證明這些目標實際上是通過實施 CTOR 實現(xiàn)的。此外，作為一項共識變化（且具有高度爭議），實現(xiàn) CTOR 存在重大的相關(guān)風險，且沒有證明其益處。出于這些原因，nChain 認為不應該實現(xiàn) CTOR提議。