比特幣規範交易排序：批判性評估
本檔案是對 ofollow,noindex" target="_blank">規範交易排序提議 （CTOR）的評估，該提議旨在改變比特幣現金（BCH）網路中塊內交易的排序。 （nChain認為BCH是真正的比特幣。）在總結提議後，我們根據常規變更管理標準評估了提議的變更。
由於下列討論的原因，我們認為沒有足夠的證據表明CTOR提議將實際提供其聲稱的益處，並且實現這種有爭議的共識變更的風險超過任何未經證實的回報。因此，我們認為CTOR提議不應在任何比特幣現金實現中實施。
1 CTOR 提 議
目前，BCH塊內的交易排序是一種鬆散的部分排序形式：
- 第一筆交易是 Coinbase 交易 ；
- 如果交易在同一區塊中花費另一筆交易的產出，則支出交易必須在交易所花費的交易之後；
- 所有其他交易–即花費先前區塊交易所獲產出的交易 – 可以按任何順序出現。
這被稱為 交易拓撲排序 （TTOR）。
規 範交易排序提 議 (CTOR)旨在根據如下方式改變區塊內交易的排序：
- 第一筆交易是 Coinbase 交易 ；
- 所有其他交易按交易ID字母順序排序。
CTOR提議聲稱跟TTOR相比有多項優勢，即：
- 消除一類可擴充套件性的挑戰
- 緊湊型包含/排除證明
- 選擇加入交易的本地化
- 塊發射和傳播的效率提高
- 軟體實現簡化
- 潛在攻擊媒介的緩解
在 後 續文章中 ， 其聲稱CTOR是分割比特幣的先決條件，它本身被定位為CPU開發從單核效能提升到多核產品的轉變之後的下一步。
2 社群反 應
CTOR引發了比特幣社群內部的爭論，激烈地提出了贊成和反對它的各種意見。下面總結了這些意見，這也明顯表明CTOR面臨著重大的反對意見，或者至少說，面臨著關於是否應該實現的嚴重問題。
- 在 私人 v s 去信任分片 中，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) 觀察到根據 Gavin Andresen 的建議，可以遵循當前的共識規則實現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 提 議
任何改變現有系統的提議都應根據多項標準進行評估，包括：
- 範圍
- 風險
- 回報
- 實現成本
- 投入市場時間
- 維護影響
- 技術資源的可用性
- 外部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順序列出，因此交易不包括在內：
如果查詢的交易TX B落在具有不同父節點inode 3和inode 4的兩個葉節點TX A和TX C之間，則很難馬上清楚地瞭解證明的保持方式，因為它們不會再在其Merkle證明中共享公共路徑：
即使假設在具有不同父節點的連續葉節點之間可能存在排除證明，排除證明也繫結到了單個塊的範圍。為了證明排除整個塊鏈，必須為鏈中的每個塊生成證明。
鑑於無法使用此方法為迄今為止開採的任何塊生成排除證明，因此無法生成全鏈排除證明。
其沒有提出排除證明的用例，也沒有得出它們是由CTOR啟用的結論。沒有提供包含證明緊湊性的實證。
範圍限制
在一篇題為 關於令牌協議的緊湊證明 的帖子中，Joannes Vermorel（CTOR提案合著者）提出了緊湊令牌證明的概念。在提及 緊湊的包含 / 排除證明 時，CTOR提議指的可能是這篇文章。
該文討論了輕量級客戶端可能僅下載一些塊資料的兩種方式。第一種是請求ID在給定範圍內的所有交易。這種想法的擴充套件是通過使用類似於虛榮地址挖礦的過程，應用程式使用者可以特意針對給定的雜湊範圍來確保某種型別的所有交易（在引用的文章中，指令牌交易）都屬於這類。文章中接著提到，這將允許輕客戶端按交易ID範圍請求塊的子集，並且僅有CTOR能實現這一點。
雖然我們與Joannes Vermorel合作開展了一個專案，但我們相信他的上述論點肯定是錯誤的。
- 無法保證交易的提交者將首先在目標範圍內按虛榮地址挖掘交易ID。
- 沒有任何機制可以阻止另一方採用相同的範圍進行虛榮地址挖礦，從而降低了該計劃的有效性。
- 建議這種虛榮地址挖礦過程和隨後的基於範圍的交易查詢只有在啟用CTOR時才能實現，以在根本上不分離IT系統的職責。如果希望按雜湊ID範圍提供資料查詢，則應配置基礎資料儲存以支援此類查詢，或者如果不能實現，則應將資料儲存遷移到可以實現的方案。應提供此類查詢模式的RPC端點。資料儲存/檢索和輕量級客戶端端點服務是兩個獨立的職責，應該分別處理。將塊傳播問題與第三種謹慎責任混為一談是一種糟糕的工程實踐 。
第二種建議方式，即輕量級客戶端可以僅下載所有塊資料的子集的方式，是指客戶端僅每過n個塊進行下載，對於n的某些定義，意味著客戶端將僅下載每n個塊中的1塊以找到相關交易。該建議承認由提交者確定交易將被開採的區塊高度的不切實際性，因此這裡不再進一步討論。
1.1.1 選擇加入交易的本地化
交易本地化是第一方重複管理交易（通過任何方法，例如重新生成簽名）直到交易ID在交易建立者可接受的範圍內的過程。它然後會被提交給網路，並且將根據CTOR接近於其他管理的交易以符合同一ID範圍。
CTOR提議表明這個目標沒有益處，儘管如上一節所述，範圍受限的輕量級客戶端查詢可能是潛在的驅動因素。
後續分片提議建議使用交易ID作為分割槽鍵來進行分片處理過程。如果交易本地化建議的意圖是允許那些向網路提交交易的人試圖以給定的分片為目標，那麼這是一個有缺陷甚至可能是危險的建議。
這無法保證給定節點將會執行特定數量的分片，因此無法保證這將確保本地化交易將會位於特定分片上。此用例也沒有明確的益處。最後，攻擊者可以通過生成具有窄範圍識別符號的交易來使用此行為，使得一個分片超載。這是一種與後續分片提議特定相關的拒絕服務攻擊形式。
1.1.2 塊發射和傳播的效率提高
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和類似塊傳播技術的益處很小。
1.1.3 軟體實現優化
軟體越複雜，以下方面難度越大：
- 驗證
- 維護
- 推論
- 提升新開發者技能
- 發現錯誤
因此，降低軟體實現的複雜性是一項合理目標。
CTOR提議討論了將交易驗證程式碼從當前的一次通過演算法更改為兩次通過Out-Then-In（OTI）演算法。兩者都比較容易理解，因此雖然不是更復雜，但肯定不會太簡單。
值得商榷的是，跨執行緒、程序甚至機器擴充套件的節點的任何實現是否都不再需要拓撲順序，並且在這種情況下，CTOR可能會減少工作負載。但是，鑑於在跨機器共享工作時追蹤TTOR的排序是微不足道的，簡化情況尚未得到證實。
在 目前的形式 中，CTOR沒有實現這一目標。相反，它會向程式碼庫中新增其他行為。在分析比特幣ABC 0.17.1和0.18.1 之間的所有變化時，很難看出複雜性方面有任何重大變化。
1.1.4 潛在攻擊媒介的緩解
CTOR提議包含一個附錄，其中說明了CTOR比TTOR更容易實現，來處理重大塊（超過10GB）。附錄的理論認為，這種簡單性表明未來攻擊媒介的潛力較低。
這種說法既沒有充分的推理支援，也沒有證據支援。
1.2 實現成本和投入市場時間
初看起來，CTOR可能不是一個重大變化，因為本身進行更改的開發成本並不大。但是，測試每個節點實現是否使更改與其他所有實現互相相容的成本要高得多。兩者都沒有明確量化。
由於變化本身很小，交付時間很短。然而，由於變化的性質，上市時間應該得到延長。作為一項共識變化，BCH開發社群應該花費足夠的時間在相容測試節點上。
這還沒有開始，因為節點實現類介面仍然存在爭議，一些團隊根本沒有實現CTOR提議。
1.3 維護影響
在維護方面，沒有發現影響。程式碼更改很小，很容易理解。在此更改後，無需其他技能即可繼續使用程式碼庫。
1.4 技術依賴性
CTOR提案沒有引入額外的技術依賴性。
CTOR提議的定位是對未來價值交付的依賴，主要是作為擴大規模處理增加的交易量的先決條件，並且最終的塊大小比我們今天看到的要大許多個數量級。
目前尚未充分證明CTOR對於實現未來的擴充套件是必要的。
1.5 非功能性需求影響
實現CTOR提議所需的程式碼更改在概念上很小，理論影響可以忽略不計 – 即既不顯著積極也不消極。
沒有釋出非功能性測試的結果來支援這一點。
2 評 估摘要
雖然一些CTOR提議的目標乍一看似乎很了不起，但沒有充分證明這些目標實際上是通過實施CTOR實現的。此外，作為一項共識變化（且具有高度爭議），實現CTOR存在重大的相關風險，且沒有證明其益處。出於這些原因，nChain認為不應該實現CTOR提議。
Note: Tokens on the Bitcoin Core (segwit) Chain are Referred to as BTC coins. Bitcoin Cash (BCH) is today the only Bitcoin implementation that follows Satoshi Nakamoto’s original whitepaper for Peer to Peer Electronic Cash. Bitcoin BCH is the only major public blockchain that maintains the original vision forBitcoin as fast, frictionless, electronic cash.