觀點：為什麼IBM的區塊鏈不是真正的區塊鏈？

翻譯：頭等倉（First.VIP）_Maggie

原文作者Stuart Popejoy在為金融業建立交易系統的方面擁有15年的經驗。在2016年與Will Martino共同創立Kadena並成為公司總裁之前，Stuart在摩根大通公司新產品部門工作，領導並開發了摩根大通的主要區塊鏈產品Juno。Stuart還為摩根大通編寫了演算法交易腳本，後者為他創建Kadena公司的簡單的、專門構建的智能合約語言Pact提供了信息。

IBM與Hyperledger Fabric

IBM是企業區塊鏈領域的主要參與者，提供基於Hyperledger Fabric的區塊鏈平台，並與沃爾瑪和Aetna等大型公司啟動了區塊鏈試驗。

IBM作為非營利開源組織Hyperledger基金會的眾多貢獻者之一（包括最近宣布的Microsoft和Salesforce），投入了巨額投資來推廣Fabric作為私有或「許可」區塊鏈，這意味著它提供了與知名的區塊鏈（如比特幣或以太坊）完全不同的功能，同時以某種方式刪除了可能「不適用於企業」的任何方面。

但是，IBM實際推廣和稱呼的所謂「區塊鏈」技術（即Hyperledger Fabric）其實犧牲了真實區塊鏈的最重要功能，無論是經過許可的區塊鏈還是公共區塊鏈。Fabric的體系結構比任何區塊鏈平台都要複雜得多，同時防範篡改和攻擊的安全性也較低。您可能會認為「私有」區塊鏈至少會提供可伸縮性和性能，但Fabric卻不。簡而言之，在Fabric上的任何構建都將面臨複雜性和不安全性，無法隨業務規模擴展。

市場上的區塊鏈選項

筆者2016年在摩根大通工作時，領導了一個新興技術團隊，該團隊研究並審查了區塊鏈以了解該銀行的潛在用途和戰略投資。這涉及對Hyperledger，Axoni，Symbiont，Ripple和Ethereum的早期版本的深入分析。當時很明顯，市場上的區塊鏈選項在技術上不足以用於實際的企業用例。不幸的是，我們今天在Hyperledger Fabric中看到了同樣的問題。

當時提出的問題包括：區塊鏈的智能合約語言如何安全、簡單地表達複雜的業務規則？如何保證公鑰簽名有效？系統是否可以擴展以納入更多的參與者（節點）且不會大幅降低性能？對於採用區塊鏈的具有前瞻性的企業，是否可以輕鬆地與其他公共或私有區塊鏈進行互操作？

使用這些問題作為框架，筆者相信IBM的系統從根本上缺乏區塊鏈所需的元素，並且具有令人誤解的性能數字和令人存疑的長期業務可行性。儘管筆者和同事們並不認為性能數值（每秒交易量，節點數）是採用區塊鏈的唯一因素，但他們確實認為為人們科普關於區塊鏈的實質是很重要的。這項教育有望幫助每個人更好地了解區塊鏈新興技術的前景。

什麼是區塊鏈？什麼不是？

為了真正了解IBM區塊鏈的地位，我們需要看一下區塊鏈本身的定義。區塊鏈的核心是事件或交易的去中心化的、不可變的分散式賬本，其全網共識是通過共識機制強制執行的。在像比特幣和以太坊這樣的公共區塊鏈中，這種共識是通過工作量證明或稱為「採礦」的行為來實現的。在私有鏈（或許可鏈）中，可以通過提供加密簽名的參與者對所寫內容進行投票來達成共識。無論哪種方式，沒有中央機構可以對任何事情進行仲裁。

IBM對區塊鏈的定義捕獲了區塊鏈的分散式和不可變元素，但省去了去中心化的共識——這是因為Hyperledger Fabric 根本不需要真正的共識機制。相反，它建議使用一種稱為Kafka的「訂購服務」。問題在於，如果沒有參與者之間的強制性，民主化和加密安全的投票，就無法證明有人沒有篡改分類帳。容錯共識（fault-tolerant consensus）是區塊鏈的標誌性特徵，沒有它，IBM的「區塊鏈」僅是帶有時間戳的條目列表。

Fabric的體系結構暴露了許多漏洞，這些漏洞可以被惡意協調利用。例如，它在網路內部引入了帶有驗證者簽名的公鑰加密技術，該簽名者提供了主要的安全保證，但在提交外部簽名的交易後才開始。這從根本上摒棄了比特幣和其他真實區塊鏈的可靠安全模型，在該模型中，任何交易的來源僅由外部用戶的公共密鑰簽名來保證，並且系統不能以任何方式進行干預。與之形成鮮明對比的是，與Fabric達成共識的唯一簽名是驗證者的簽名，而用戶簽名消失在通過網路複製的任意數據集中。

（圖：在Hyperledger Fabric v1.0中交易的周期）

Fabric研究人員對性能指標的態度搖擺不定，因為從根本上說，Fabric的體系結構無法在保持峰值性能的同時進行擴展。Fabric使用多鏈環境（稱為「渠道」）在參與者之間提供隱私性。提供隱私性是私有「企業」區塊鏈的一項重要功能，並且必然涉及權衡和複雜性，但是對於可伸縮性而言，多鏈解決方案是一個糟糕的選擇。它還使節點的部署變得異常複雜，節點不統一，智能合約不可靠以及潛在的故障點激增。

因此，標準Fabric部署的性能數值啟動起來並不盡如人意，隨著節點的增加，性能數值會迅速下降，並且是單通道的：如果要跨多個通道與整個網路進行交易，這些數值甚至都沒有關係。即使這樣，在查看單個通道時，該系統也很難獲得每秒800個以上的事務（TPS），但是即使是16通道的配置也幾乎不能超過1,500 TPS，就算是在保持10到20秒的延遲範圍內實現高吞吐量也不行。

最近Fabric為加快速度做出了一番努力，聲稱達到20,000 TPS的速度。但是研究人員對體系結構所做的更改與區塊鏈相距甚遠，以至於根本看不出區塊鏈的影子：代言人不再充當驗證者，Kafka被奉為唯一可能的訂購服務（從理論上講，Fabric可以接受真正的區塊鏈共識，但是它是如此之慢，以至於沒人會在生產中使用它）。最後，這些仍然是單通道數值，這意味著作為共享真相來源的整個區塊鏈概念無效。

為什麼智能合約和混合操作很重要

考察區塊鏈時，要考慮的最後一點是它們打算如何擴展到私有資料庫之外，以及它們的工具（例如其智能合約語言）如何幫助企業更大範圍地成功。記住，智能合約不僅僅是一段代碼，它代表業務邏輯。智能合約可以在區塊鏈上保護房屋，確保數字身份，甚至代表買賣二手車的人之間的代管交易。重要的是，智能合約必須可靠並且不可篡改。

在區塊鏈上構建任何東西時，您需要能夠通過智能合約表示您想做什麼（購買，出售，打包數據等）。使用的語言越簡單，就可以越快地構建所需的東西並將其展示在利益相關者的眼中。更重要的是，智能合約的功能最好是能為業務實際產生收入或取得一些積極成果。

Hyperledger Fabric的智能合約（chaincode）可以用多種編程語言編寫，包括通用Javascript或Go。但是，在已經知道通用語言的程序員的便利性與特定於領域的語言所提供的安全性之間存在一些折衷。當風險與區塊鏈一樣高時（如果代碼不是針對區塊鏈而設計的，那麼如果代碼有錯誤或不正確，可能會損失數百萬美元），智能合約語言必須經過專門設計且設計安全。理想情況下，在所需的區塊鏈環境中也將易於學習且易於使用。在這方面，Chaincode很大程度上失敗了——花了大約150行代碼，只是執行經典的程序員教程的「hello world」輸出。而這大量的代碼可能催生數百萬美元的錯誤。

IBM還沒準備好迎接未來

越來越多的區塊鏈生態系統最老練的觀察者意識到私有和公共區塊鏈之間將不會存在真空，而是希望攜手合作：私有鏈將希望向公共區塊鏈上的消費者提供令牌，而公眾區塊鏈的去中心化應用程序將希望將敏感信息存儲在私有區塊鏈上。不幸的是，IBM Fabric（以及R3 Corda）的用戶可能會因為架構的完全不兼容而發現自己與公共區塊鏈「隔絕」，而且由於其智能合約語言無法在公共和私有環境中無縫執行。

隨著IBM通過宣布合作夥伴關係在許多企業區塊鏈新聞周期中佔據主導地位，重要的是要深入研究該技術的實際作用。IBM的「區塊鏈」技術在很多方面都缺乏，包括安全性，性能和可靠性，這為希望使用區塊鏈實現有意義的業務改進的組織提供了「劣等的」解決方案。為了真正實現區塊鏈的價值，成熟的客戶將尋求IBM的挑戰者，他們提供更好的工具、更好的區塊鏈技術以及如何利用技術的更好的願景。