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

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

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

我們能選擇的區(qū)塊鏈有哪些？

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

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

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

區(qū)塊鏈應是什么？不是什么？

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

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

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

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

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

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

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

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

智能合約是一種商業(yè)邏輯

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

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

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

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

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

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

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