IBM是企業區塊鏈領域的重要參與者，其區塊鏈平臺以 Hyperledger Fabric 超級賬本為基礎，為很多大企業比如沃爾瑪和安泰保險都開發過區塊鏈試點產品。

Hyperledger 基金會是一個開源的公鏈項目，屬于非盈利機構。作為機構的贊助商之一（最近微軟和軟件服務公司 Salesforce 也宣布入駐 Hyperledger），IBM 投入了大量資金，計劃推動機構向私有鏈或“許可鏈”方向發展。IBM 似乎有他自己的投資意圖：Hyperledger 既要與業界知名的比特幣和以太坊等公鏈保持共通性，也要去除掉身上“不適合企業發展”的特點。

但不管公有還是私有，IBM 這種既保公鏈，又搞創收的行為恰恰忽略了 Hyperledger Fabric 區塊鏈最重要的特征。Fabric 的架構比任何區塊鏈平臺都復雜，同時，面對未來可能的篡改和襲擊風險也不夠牢靠。你可能想，畢竟是“私有鏈”，多少有擴展性和效率的優勢，但很抱歉，Fabric 在這方面也好不到哪兒去。簡單說，基于 Fabric 建立的試點項目在部署過程中會面臨很多復雜因素和不安全狀況，未來擴展到其他企業的可能性不大。

我們能選擇的區塊鏈有哪些？

2016 年，我還在摩根大通的時候，曾領導一個新興的技術小組負責研究和審查市面上的區塊鏈項目，為公司未來的戰略開發和投資作鋪墊。我們對 Hyperledger、Axoni、Symbiont、Ripple 和以太坊等早期版本都做了深入分析。當時我們發現，市面上的區塊鏈項目在技術上都不足以支撐企業的應用。 非常遺憾的是，當時的問題在今天的 Hyperledger Fabric 上仍然存在，而且是核心問題。

問題有很多：區塊鏈的智能合約語言如何將復雜的商業規則以安全簡單的方式表達出來？公鑰簽名如何保證有效？區塊鏈系統如何在不減緩效率的前提下擴展更多的節點？還有，作為一家面向未來的公司，如何與其他的公鏈和私鏈輕松做到交互操作？

從這些問題看，我認為 IBM 的區塊鏈系統缺乏區塊鏈的必要元素，不僅其效率指數可能給企業造成誤導，而且在保證企業的長期生存能力方面也要打個問號。雖然我和同事不應該只把效率（比如每秒交易量和節點數等）作為區塊鏈技術的唯一衡量因素，但我們認為，大家有必要知道區塊鏈應該是什么不應該是什么。厘清這個概念有助于我們更好地理解區塊鏈這項新技術的變化。

區塊鏈應是什么？不是什么？

要想真正理解 IBM 的區塊鏈立場，我們需要看看區塊鏈的定義。所謂區塊鏈，其核心要義是記錄項目和交易數據的不可更改的去中心化賬本，實際的交易記錄通過共識機制執行。在比特幣和以太坊等公鏈中，共識機制的實現方式是工作量證明機制，俗稱“挖礦”。在許可鏈中，共識機制的實現方式是參與節點提供加密簽名，對書面條款投票表決。不管哪種鏈，都沒有中心機構參與其中。

IBM 的定義抓住了區塊鏈的分布性和不可篡改性，但忽略了去中心化共識，這就是為什么 Hyperledger Fabric 沒有對真正的共識機制提出要求。取而代之的是，它使用了一種叫做 Kafka 的“訂閱系統”。但問題是，只有參與方強制執行了民主式投票機制，我們才能證明賬本信息未被篡改。容錯機制是區塊鏈的標志特征。如果沒有容錯機制，IBM 的“區塊鏈”幾乎跟時間戳也沒什么兩樣了。

Fabric 的架構同時暴露了很多弱點，這些弱點很容易被不法分子利用。例如，Fabric 在驗證者簽名的“網絡內”上使用公鑰加密技術，這種做法確實提供了安全保證，但前提條件是，只有當外部簽名交易提交后才可啟動。

從根本上來看，比特幣及其他真正區塊鏈系統已驗證的安全模式可能失效。在比特幣等真正的區塊鏈系統中，交易記錄只能通過外部用戶的公鑰簽名確定，任何形式的中間力量都無法參與到系統中。但是，Fabric 共識機制中真正重要的簽名屬于驗證人，而用戶簽名在任意數據集的網絡復制過程中往往不受重視。

Fabric 的研究者之所以不斷強調效率指數（比如交易速度等），就是因為 Fabric 的架構無法在保持高效率的同時進行擴展。Fabric 運用多鏈環境（通道）為用戶保密。保護用戶隱私是私有“企業”鏈的一個重要特征，不可避免會涉及很多權衡和復雜因素，但是多鏈方案不適合擴展。而且在節點部署方面也很復雜，各節點參差不齊，智能合約可靠性低，單點故障容易擴散。

所以，對于一個標準的 Fabric 部署來說，效率指數高不能說明問題。隨著節點數的增加，通道重新恢復為單通道，效率指數也會迅速降低：如果你想通過多通道與全網做交易，效率指數沒有多大參考價值。即使你看見單獨通道的每秒交易量已拼命達到 800 以上，但 16 個節點的通道參數也不會超過每秒 1500，節點參與量一旦變高，延遲可能達到 10-20 秒的長度。

最近，Fabric 下了大功夫，據說每秒交易量被提高到了 20,000 的水平，但研究者在架構層面做出的改變大大偏離了區塊鏈的本質，以至于改后的架構屬性面目全非：贊助人無法承擔驗證者的角色，而且 Kafka 系統作為唯一的訂閱系統也成為擺設（從理論上說，Fabric 可以采用真正的區塊鏈共識機制，但速度會很慢，實際應用的可能性不會很高）。

最后一點，速度指數只停留在單通道層面，意味著區塊鏈無法成為整體的共享信息來源。

智能合約是一種商業邏輯

面對區塊鏈，最后一個考慮的點是：它如何超越私有數據庫進行擴展？區塊鏈工具（比如智能合約語言）如何幫助企業取得廣泛的成功。

請記住，智能合約不是所謂的“代碼”，它是一種商業邏輯的體現。你可以通過智能合約在區塊鏈上買房，確認自己的數字身份，或者買賣二手車。所以智能合約的可靠性非常重要，條款是什么，就按照什么執行。

如果你想在區塊鏈上創建什么東西，你需要通過智能合約描述自己想做什么東西（比如實物交易、打包數據等等）。你描述的語言越簡單，創建的速度就越快，也能更快讓項目方看到成果。更重要的是，你需要智能合約獲取收益或者給你的企業帶來好業績。

Hyperledger Fabric 的智能合約（“鏈式碼”）一般由幾種編程語言寫成，包括通用的 JavaScript 語言和 Go 語言，但是需要權衡編程語言的便利性和安全性。如果區塊鏈涉及的利益很大，比如如果程序出現 bug 或者寫錯了，導致上百萬美金丟失，那編程語言確實應該目的明確，設計的時候把安全放在首位。在理想的區塊鏈環境中，智能合約語言應該好學也好用，但實際情況不可能如愿以償。我們知道，要成功完成經典的程序演示“Hello world”，需要寫 150 行左右的代碼。代碼量如此之大，自然容易產生可能造成上百萬美元損失的 bug。

私有鏈和公鏈不會毫無關系

區塊鏈領域資深的觀察家正意識到，私有鏈和公鏈不會毫無關系，兩者在未來會發生聯系。私有網絡想發行代幣給公鏈用戶，而公鏈的去中心化應用也想在私有鏈中儲存機密信息。但不幸的是，IBM Fabric 用戶僅僅因為架構無法兼容，就被“隔離”在公鏈之外。不僅如此，他們因此也錯過了智能合約語言的學習機會，無法在公鏈和私有鏈之間實現無縫操作。

隨著 IBM 宣布建立企業區塊鏈的消息持續成為媒體關注的焦點，我們需要看清楚聚光燈之下，這項技術到底有何作為。Hyperledger Fabric 很多方面的標準性不足（包括安全性、效率和可靠性等等），因此，想借助區塊鏈技術尋求發展的公司或機構無法得到有價值的解決方案。要想真正理解區塊鏈的價值，資深用戶會尋找更有優勢的服務公司，因為他們能提供更好的區塊鏈技術，對未來的發展和技術的應用方式也有更好的規劃。

作者介紹：

Stuart Popejoy，涉足金融領域 15 年，在貿易系統和交易平臺框架創建方面擁有豐富經驗。曾供職于美國摩根大通公司的新產品研發部，期間領導開發了摩根的區塊鏈主打產品——Juno。Stuart 還參與編寫了摩根的算法交易腳本，為日后 Kadena 簡潔特定的智能合約語言奠定了基礎。離開摩根后，與 Will Martino 在 2016 年聯合成立智能合約創企 Kadena，任公司總裁。
責任編輯；zl