論CTOR新增到11月BCH協議升級
作者：Jonald Fyookball
規範交易排序（CTOR）是一項計劃在2018年11月比特幣現金協議升級時做出的更改。比特幣現金社群對這項更改進行了大量的討論。
我之前發表過一篇文章簡要說明過這項更改是什麼。
儘管那篇文章解答了部分讀者的疑問，並說服了他們CTOR並不危險，但其他人仍有微詞並想知道這項更改是不是必要的。
許多人提出的問題是：“我們為什麼要規範交易排序？我們為什麼現在要規範排序？有沒有其他同樣可以完成規範交易排序的方案？”
我試圖在本文中回答這些問題。
CTOR是一個全面的技術路線圖的組成部分，旨在推動比特幣現金成為全球性的點對點電子現金。更具體來說，CTOR的主要好處是可以提高區塊傳播的速度。同時還附帶一些小的好處。
遺憾的是，很多關於CTOR的技術討論都是在談區塊驗證而不是區塊傳播，這讓整個爭論變得非常的複雜和混亂。
回顧4種不同的交易排序方案
讓我們首先回顧一下4種不同的比特幣現金交易排序方案。
1．TTOR 拓撲交易排序規則
這是比特幣現金當前的共識規則。交易有一個部分排序規則。交易可以任意排序但是必須要進行拓撲排序，即母交易要放在子交易的前面。
2.ATOR 任意交易排序規則
這個排序規則將會移除現在的TTOR，允許交易自由排序。這個排序規則曾被當作是CTOR排序規則的替代方案進行討論過，也是CTOR的前身。
3. GTOR加文（Gavin）的交易排序規則
這是2014年加文·安德魯森（Gavin Andresen）提出來的。本質上就是一種規範交易排序，但是這個排序並不是強制執行的（非共識層的）且還會保留當前的TTOR規則。
4. CTOR 規範交易排序規則
這是本文提到的方案。“規範”指的是規定只允許一種排序規則。這種方案是“詞典式（lexical）”或是“字典式（lexicographic）”，也就是說，除了coinbase交易外，區塊裡的所有交易都要按照字典順序排序。有些人在討論時將其稱之為LTOR。
為了簡明，即使從某個點來看更符合詞典編撰的屬性，下文也統一把這個方案稱為CTOR。
區塊傳播
讓我們從頭開始說起。2014年，加文提出一個新的區塊傳播方式，他的想法是規範區塊裡的交易排序。他提案裡的“祕訣”是讓節點通過使用可逆的布隆查詢表(IBLT) 來相互溝通，以讓節點識別記憶體池裡的交易集和其他節點之間的差別。
這個想法後來成為現在著名的石墨烯（Graphene）協議的基礎。
當前所有的BCH實現方案都沒有采用加文最初的排序方案，但是說明這個想法的歷史根源很重要，因為CTOR目前最明顯的應用就是有助於更好地實現石墨烯（Graphene）。
關於為什麼要有獨特的排序，一個更直觀的解釋就是，可以加快傳播速度，節省頻寬，你只需要廣播遺漏的交易，不用溝通區塊裡已排好序的交易。規範排序有助於其他區塊鏈傳播方案的實現，例如極瘦區塊（Xthin），它的好處並不僅限於石墨烯（Graphene）。
有一名開發者發表了一篇評論文章表示，CTOR對於改善區塊傳播並沒有太大用處，因為礦工可以根據當前的規則，選擇對自己的交易進行重新排序。但是，並沒有解釋這樣如何提高效率，只給了一個帖子的連結，帖子稱：“……剩下的交易完全可以隨意進行重新排序。例如，按照txid進行排序……”
換句話說，不規範排序的話，礦工就可以自由選擇一種規範排序？
如果他的點在於自由選擇，我們稍後會再討論這個問題。
還值得注意的是，這篇評論文章的作者（Awemany）發表文章和參加曼谷礦工會議後，改變了他對CTOR的觀點……他強調，任何一項提案都不值得分裂BCH。
區塊驗證
CTOR方案的一個好處是簡化並行區塊驗證。這是移除拓撲交易排序規則的結果。但是，並行驗證並不是一個。即使按照當前的拓撲排序的方案，也可以並行驗證。
關於區塊驗證的整個爭論有點像是（並非出於本意的）障眼法，因為區塊傳播的瓶頸要比區塊驗證大得多。
我們重新回顧下這個話題的主要論點可能會有助於讀者理解。最初辯論的過程是這樣的：
反對CTOR的人認為，（至少在一個簡單實現裡）節點根據TTOR可以更快地驗證交易，因為每筆交易的前置項都是已經處理過的。而CTOR支持者則認為，拓撲的限制是一個需要驗證的額外負擔（換句話說，你不能簡單地把區塊裡的交易進行分割槽，然後並行處理。）
Jonathan Toomim接著釋出了一個演算法，演示如何通過先處理output，再處理input（例如OTI），使用現行的拓撲排序完成並行驗證。
OTI的方法可以適用於TTOR和CTOR。如果是TTOR，需要在第一個迴圈生成每筆交易的定點陣圖，第二個迴圈要確保每一筆交易只發比它自身更早的幣。這裡必須要進行多個迴圈，這使得TTOR在簡單實現裡的優勢變成一個有爭議的問題。
總的來說，TTOR和CTOR都可以並行驗證。最初的測試表現大致相同。但是需要重申的是，這是次要的問題，因為CTOR顯然有助於解決區塊傳播這個更重要的瓶頸問題。
CTOR的其他好處
CTOR還有其他一些好處。UTXO的處理也許會得到改善，因為按次序插入可以利用樹結構讓UTXO快取更高效，同時提高UTXO證明（UTXO commitments）的可能性。
SPV/輕錢包可以從不包含某筆交易的證明獲得好處。CTOR也可以允許使用梅克爾樹結構和驗證來實現路由分片。
不過第二大好處應該是簡化程式碼。讓交易自由排序，就必須要支援所有排序，
會讓程式碼變得更加複雜。相比之下，按照字典順序排序，區塊結構每次都是相同的，測試會變得更加簡單。
TTOR vs ATOR vs CTOR
有些關於區塊驗證的論點並不是專門針對CTOR的；更像是一個TTOR vs ATOR的問題。換句話說，我們是否應該保留這種拓撲交易排序規則，還是該移除？
有些專家已經指出，從本質上來說，交易排序並沒有什麼內在價值。我對此的理解是，雖然拓撲排序處理從屬項是事實，但最開始建立這種排序是需要（時間）成本的。大部分開發者並不反對移除TTOR。甚至nChain那些領導開發者也是這麼認為的。
另外，拓撲排序規則被移除，對於規範排序來說是一個很小的變化。這是CTOR方案背後的原則之一。在ABC實現裡，在ATOR的頂部新增CTOR就是20行程式碼的事。
反對“中央計劃”
反對CTOR的其中一個觀點（似乎不成立）是，礦工應該自由選擇如何排序，他們應該“競爭”用最好的方式構建區塊，強迫他們執行一項命令就等於是“中央計劃”。
我是所有形式的自由市場的堅定支持者。但是，礦工應該在交易排序上競爭這個想法，與在交易格式、ECDSA曲線引數，或是許多協議細節上競爭相比沒有什麼差別。
協議的特定部分就相當於基礎設施裡的“管道”。它可能會對系統產生反作用，因為所有節點也必須支援一個低效的排序方式。
反對“優化優先”原則
有些開發者（尤其是Tom Zander）表示希望繼續用拓撲排序優化程式碼。他們不想升級或改進交易排序，因為他們認為應該探索和窮盡當前方案的所有可能性。
協議的開發不應該僅僅是因為某個開發者想要繼續按照特定軌道進行探索這個理由而停滯不前。
儘管優化現行程式碼可能也是一種方法，但這未必是最好的方法。我們最終必須選擇一條明確的道路，即使這意味著要放棄其他的道路。
更重要的是，這種方法優先考慮在選擇正確資料結構上進行優化，這與計算機程式設計的最佳實踐背道而馳的。18
發展路線圖
Bitcoin ABC釋出了一個技術路線圖，詳述瞭如何改進協議，以實現我們的目標，讓BCH更好地擴容、擁有更好的實用性和可擴充套件性。
CTOR在這張路線圖上是一個很小但很重要的組成部分。
儘管比特幣現金社群的規模要比Bitcoin ABC大得多，但應該指出的是，自2017年11月召開多方會議後，ABC的發展路線圖與其他各個團隊發表的路線圖宣告是一致的。實際上，規範交易排序方案與nChain在2017年12月提出的路線圖完全一樣的。20
從整體出發的方法也許是最好的
我們不應該把CTOR當作一個獨立的協議更改來進行評估，而是當作Bitcoin ABC作先鋒計劃周詳的技術方案裡一個不可缺少的組成部分。
BCH協議擴容不是隻有一種方法，但採用一種從整體出發的合理方案更可行，而不是採用基於相互孤立的更改和“hacky”fixes的方案。
例如，我們可以使用GTOR得到規範交易排序所帶來的一些好處，但是它需要在重建石墨烯區塊的過程中進行一次拓撲排序，這樣會變得更加複雜。
還可以選擇實現OTI演算法，在使用拓撲排序的情況下進行並行驗證，但是如果CTOR就能做到這點，提供切實的好處並簡化程式碼，那麼為什麼要採取這種迂迴的方式呢？
CTOR是一項安全且經過驗證的協議更改嗎？
正如在“ELI5 article”文中解釋的，從根本上來說，使用不同的交易排序並不是一項重大改變。
雖然進行更多的測試和基準測試是好事，但是建立正確的資料結構，我們才能著手下一步的開發工作。幾個團隊花數個月的時間在不保證以後還會存在的協議更改基礎上進行開發工作，這是不切實際的。
大部協議更改都要在風險與回報之間做取捨。我曾看到過一條誤導人的評論，更改應該在測試網上經過3-5年的驗證才能進行部署。但是，過度謹慎，超出了合理的範圍，想要以此來降低風險，這並不是個明智的做法。
我們正在與傳統的支付方案以及其他的加密貨幣在競爭，我們還在與自身競爭，要在區塊獎勵減半之前擴大交易量。我們需要深思熟慮預測可能帶來的風險，但是這也可能會讓我們停滯不前。
CTOR新增到路線圖上已經有近1年的時間，並且多年來已經進行過大量的討論。
作為一個對現行系統的挑戰者，我們必須要優於這個系統一個數量級。我們必須要儘早為擴容建立技術基礎，這樣企業和應用才會有信心選擇BCH這個平臺。
最後，BCH壓力測試期間收集到的資料裡可以找到確鑿的證據，證明石墨烯（Graphene）將極大從CTOR受益。
結論
CTOR提案引發了大量的爭論、討論和混亂。重新審視之後，CTOR看起來是一項明智的更改，有明顯的好處，沒有明顯的缺陷。它是經過規劃的BCH擴容發展路線圖的組成部分。礦工、開發者、使用者以及企業都應該支援將其加入到2018年11月進行的協議升級。
註腳
- Jonald Fyookball, “An ELI5 on Canonical Transaction Ordering”
- Mengerian, Bitcoin Forum
- Bitcoin Unlimited, Bitcoin Cash Development and Testing Accord
- Gavin Andresen, O(1) Block Propagation
- Ozisik, Andresen, Bissias, Houmansadr, Levine, “Graphene: A New Protocol for Block Propagation Using Set Reconciliation”
- u/awemany, “A Opinionated Critique of the Canonical Transaction Ordering for Bitcoin”
- Tom Zander, Bitcoin Forum
- u/awemany, r/btc
- u/jtoomim, r/btc
- Jonathan Toomim “Canonical block order, or: How I learned to stop worrying and love the DAG”
- Jtoomim “Use output-then-input block validation before fork (with tests)”
- u/jtoomin, r/btc
- Shammah Chancellor, “Sharding Bitcoin Cash”
- Jason Cox, “Benefits of Canonical Transaction Order”
- Sergio Demian Lerner, twitter
- Otaci, Bitcoin Forum
- Deadalnix, implement canonical transaction ordering
- Linus Torvald, git mailing list
- Bitcoin ABC, “The Bitcoin ABC Vision”
- nChain, Bitcoin Cash Development & Testing Accord
- Chris Pacia, r/btc
原文連結： https://docs.google.com/document/d/1Gb2juy5t61CgnkY5ZGxW4Whd24SdFREUL2iEzhEbYA8/edit
作者：黃世亮
歡迎關注微信公眾：閃電HSL
歡迎打賞BTM：bm1qefc720au672awrgazgw5c3kx7etr5kejju02p7
版權宣告： 
作者保留權利。文章為作者獨立觀點，不代表巴位元立場。