關於11月比特幣現金將添加CTOR事件

​​新的交易排序規則（「CTOR」）是2018年11月比特幣現金協議升級的計劃變動之一。 比特幣現金社區已就這一變化進行了至關多的討論。

我以前發表過一篇文章，簡單地解釋了這一變化是什麼。

雖然那篇文章讓一些讀者感到滿意而且說服他們認爲CTOR並不危險，但其餘人仍然表示懷疑，他們想知道這種改變是否必要。

許多人心中的問題是：「爲何咱們須要CTOR？ 咱們爲何如今須要它？ 還有其餘殊路同歸的作法嗎？」

我想在這裏回答這些問題。

CTOR是全面技術路線圖的其中一環，旨在幫助比特幣現金成爲全球的點對點電子現金。

更具體地說，CTOR最明顯的主要優勢就是更快的區塊傳送，固然還有一些額外的好處。

遺憾的是，關於CTOR的許多技術討論都是在區塊驗證而不是區塊傳送，這給整個討論帶來了至關大的複雜性和混亂度。

梳理4種不一樣的交易排序方案

首先，讓咱們經過研究比特幣現金交易排序的4種不一樣方式來開展分析。

1. TTOR - 拓撲交易排序規則

這是比特幣現金的當前共識規則。 交易有部分排序規則。 它們能夠是任何順序，但必須強制執行將母交易排列在子交易以前的拓撲。

2. ATOR - 任何交易排序規則

此排序將取消當前的TTOR規則，容許任何交易順序。 這個想法已被討論認爲是CTOR的替代方案和前身。

3. GTOR – 加文交易排序規則

這是由加文•安德烈森(Gavin Andresen)在2014年4月提出的。它本質上是一個規範的交易排序，但排序不是強制性的（非共識），它也保留了當前的TTOR規則。

4. CTOR -交易規範排序規則

這就是目前的提議。 「規範」是指僅容許排序的要求。 當前的提議也是「詞法」或「詞典」，意味着除了coinbase以外的區塊中的全部交易都按字典順序排序。 這在其它討論中也被稱爲「LTOR」。

爲簡便起見，本文此後將使用「CTOR」來指代當前提議（也剛好是LTOR），即便某一特定點更適用於詞彙屬性。

區塊傳送

讓咱們從頭提及。2014年，加文（Gavin）提出了一種區塊傳送的新方法，他的想法之一就是在區塊中採用交易的規範排序。 他的「祕訣」是使用可逆布隆查找表（IBLT）來傳達節點mempool中的交易集與對等交易集的差別。

這種思路也就是當前廣爲人知的Graphene協議的起源。

Gavin最初的排序提議並不屬於當前任何一個BCH的實施提議，可是從歷史上來看，展現這個想法的起源是相當重要的。現在，對於CTOR來講，最明顯的應用是它有助於Graphene更好地工做。

用一種更直觀的方式來解釋一下爲什麼獨特的排序有助於區塊傳送： 若是您只須要傳送缺失交易的數據而不是傳達區塊中交易順序的信息，就能夠節省帶寬。 所以，規範排序能夠幫助其它區塊傳送方案，例如Xthin; 所以它的好處不只僅是有助於Graphene。

在已發表的評論中，一名開發人員暗示CTOR對區塊傳送沒有好處，由於礦工能夠選擇根據當前規則從新排序本身的交易。可是，該評論沒有解釋這種作法如何提升效率，評論只提供了一個論壇帖子的連接，帖子裏說「......其他的交易徹底能夠自由從新排序。好比經過txid來實現......」

換句話說，避免規範排序就是爲了礦工能夠自由選擇規範排序？

若是隻是爲了選擇的自由，咱們將在稍後討論。

一樣值得注意的是，發表該評論的人（Awemany）在曼谷礦工會議後改變了他對CTOR的見解……他強調，任何一個提出改變的方法都不值得讓比特幣分裂。

區塊驗證

CTOR的一個好處是能夠簡化區塊驗證的並行處理。這是取消拓撲排序要求的結果。 可是，並行化不是惟一的好處; 即便在現有的拓撲排序方案下，您仍然能夠並行化該過程。

關於區塊驗證的整個爭論其實有點轉移注意力（固然多是無心的），由於區塊傳送是一個比區塊驗證更大的瓶頸。儘管如此，這可能有助於讀者瞭解關於這一話題的主要論點的前因後果。

最初的交鋒是這樣的：

CTOR批評者指出（至少在一個理想的實施方案中），節點能夠在TTOR下更快地驗證交易，由於每一個交易的依賴關係已經被處理。CTOR的支持者則指出，拓撲限制是一個須要驗證的額外負擔。（換句話說，你不能簡單地將區塊中的交易劃分爲並行分區就算完成了。）

而後Jonathan Toomim發佈了一個算法，顯示如何經過先處理輸出，再處理輸入（例如「OTI」），使用當前的拓撲排序來完成並行驗證。

OTI的方法在TTOR和CTOR中均可以應用。在TTOR的狀況下，須要在第一個循環中生成每一個交易的位置圖，而且第二個循環確保每一個交易僅花費比其自身更舊的硬幣。這裏所需的多個循環使得在理想實施狀況下實現的TTOR優點變成一個有爭議的問題。

總而言之，TTOR和CTOR均可以並行化。初步測試顯示二者效率大體相同。但重申一下，這並無太大相關性，由於CTOR顯然有助於區塊傳送，而這是一個更重要的瓶頸。

CTOR的其它優點

CTOR還有其餘一些優點。它能夠提高UTXO處理，由於順序插入能夠更有效地使用UTXO緩存的樹結構，並能擴展UTXO承諾的可能性。

SPV / Light錢包也可享受交易排除證實的微小優點。CTOR還能夠容許路由到分片，與merkle構造和驗證保持一致。

但最大的第二個好處是簡化了代碼。若是容許任何一種交易順序會使代碼更加複雜，由於要支持全部順序。相比之下，按照交易哈希排序可以讓區塊每次以相同的方式進行構造，讓測試變得更簡便。

TTOR vs ATOR vs CTOR

圍繞驗證問題的一些論據並不是針對CTOR; 他們更是與TTOR與ATOR相關的問題。 換句話說，咱們應該保留拓撲排序要求仍是取消它？

一些專家指出，從根本上說，交易的順序沒有固有的價值。我對此的理解是：雖然拓撲順序能夠處理依賴關係，但最初建立順序是有成本的。大多數開發人員並不反對消除TTOR。這甚至適用於nChain的主要開發人員。

此外，一旦廢除拓撲要求，採用規範排序也只是一個相對較小的變化。這也是CTOR提議的原則之一。在ABC實施中，在ATOR之上添加CTOR只須要增長20行代碼而已。

關於「中央計劃」的異議

對CTOR的一個反對意見（雖然並不成立）是礦工應該能夠自由地採用本身的順序- 他們應該自由地「競爭」以得到構建區塊的最佳方式，若是強制他們採用某種順序無異於「中央計劃」。

我堅決支持各類形式的自由市場。然而，礦工應該在交易排序上競爭的想法與在交易方式、ECDSA曲線參數或任何數量的協議細節競爭同樣，都沒有任何意義。

協議的某些部分只是基礎設施的「管道」。 它甚至可能對系統起副作用，由於全部節點都必須支持低效的排序方案。

關於「優化第一」的異議

某些開發人員（特別是Tom Zander）表示但願繼續使用當前的拓撲排序來優化代碼。他們不想升級或修改交易順序，認爲應該探索並窮盡現有方案的可能性。

協議開發不該由於某個開發人員但願繼續在某個路線進行探索而停滯不前。

雖然在當前協議限制內進行優化是一種可能的辦法，但它不必定是最好的方法。咱們終將選擇一條獨特的路徑，即便這意味着放棄其餘路徑。

更重要的是，這種方法優先考慮優化而不是選擇正確的數據結構，這與計算機編程中的最佳實踐背道而馳。

發展路線圖

比特幣ABC發佈了一個技術路線圖，詳細說明了咱們如何改進協議並實現比特幣現金更好的擴容性、可用性和可擴展性的目標。這是咱們將來全面、務實計劃的最佳範例。CTOR在該路線圖當中是很小但重要的組成部分。

雖然比特幣現金社區比比特幣ABC大得多，但應該注意的是，ABC路線圖能夠與2017年11月倫敦小組會議後發佈的各小組路線圖內容進行兼容。事實上，在2017年12月nChain的路線圖中也出現了徹底相同的規範順序提議。

一個綜合的方法也許是最佳方案

CTOR不該被做爲獨立的協議變動進行評估，而應做爲比特幣ABC引領的精心策劃的技術方法的一個組成部分。

比特幣現金協議擴容的方法不止一種，但採用一種「綜合的」、符合邏輯的方法，而不是基於孤立變化和「黑客」修復的方法會更有意義。

例如，咱們可使用GTOR來得到規範排序的一些益處，但在graphene區塊重建期間這會須要拓撲排序，這會更加複雜。

咱們也可使用當前的拓撲排序實現OTI算法來處理並行驗證，但若是CTOR自己就能實現，並且能提供切實的好處而且簡化代碼，咱們又何須採用零散的方法呢？

CTOR是一個安全且通過驗證的協議變動嗎？

正如「ELI5文章」中所解釋的那樣，不一樣的交易順序並不表明完全的改變。

雖然更多測試和對標會很好，但在開始進一步開發開始以前，必需要有正確的數據結構。對於某些羣體來講，若是花幾個月的時間作協議變動，卻不能保證之後還能繼續存在，這自己是不現實的。

大多數協議更改都存在風險/回報的權衡。我曾看到一個錯誤的評論，說在部署以前應該在testnet上作3 - 5年的測試驗證。 可是，若是爲了下降風險而謹慎過頭，這不必定是一種穩健的作法。

咱們正在與支付解決方案的競爭對手進行PK，包括傳統和其餘加密貨幣，以及與咱們本身PK，以便在區塊獎勵減半以前增長交易量。咱們須要一些深思熟慮的風險權衡，但與此同時也存在停滯的風險。

CTOR已經在路線圖上存在已經將近一年，而且已經進行了多年的討論。

做爲現有系統的挑戰者，咱們必須提升一個數量級。咱們必須儘早創建擴容性的技術基礎，以便企業和應用程序有信心選擇比特幣現金做爲平臺。

最後，咱們從BCH壓力測試收集到的數據中發現了確鑿證據，證實graphene將從CTOR中獲益匪淺。

結論

咱們圍繞CTOR提議進行了大量辯論和討論，也有不少混淆的觀點。通過研究，CTOR應該是一個明智的變化，它有明顯的優點，並無明顯的缺點。它是精心規劃的比特幣現金路線圖的一部分。礦工、開發人員、用戶和企業都應該支持將其歸入2018年11月的協議升級中。

 

腳註

1.Jonald Fyookball, 「An ELI5 on Canonical Transaction Ordering」

2.Mengerian, Bitcoin Forum

3.Bitcoin Unlimited, Bitcoin Cash Development and Testing Accord

4.Gavin Andresen, O(1) Block Propagation

5.Ozisik, Andresen, Bissias, Houmansadr, Levine, 「Graphene: A New Protocol for Block Propagation Using Set Reconciliation」

6.u/awemany, 「A Opinionated Critique of the Canonical Transaction Ordering for Bitcoin」

7.Tom Zander, Bitcoin Forum

8.u/awemany, r/btc

9.u/jtoomim, r/btc

10.Jonathan Toomim 「Canonical block order, or: How I learned to stop worrying and love the DAG」

11.Jtoomim 「Use output-then-input block validation before fork (with tests)」

12.u/jtoomin, r/btc

13.Shammah Chancellor, 「Sharding Bitcoin Cash」

14.Jason Cox, 「Benefits of Canonical Transaction Order」

15.Sergio Demian Lerner, twitter

16.Otaci, Bitcoin Forum

17.Deadalnix, implement canonical transaction ordering

18.Linus Torvald, git mailing list

19.Bitcoin ABC, 「The Bitcoin ABC Vision」

20.nChain, Bitcoin Cash Development & Testing Accord

21.Chris Pacia, r/btc

文章由BitcoinCash公衆號翻譯自《The Case for Adding CTOR To Bitcoin Cash in November》​​​​