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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最后一點，速度指數(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 語言，但是需要權(quán)衡編程語言的便利性和安全性。如果區(qū)塊鏈涉及的利益很大，比如如果程序出現(xiàn) bug 或者寫錯了，導(dǎo)致上百萬美金丟失，那編程語言確實應(yīng)該目的明確，設(shè)計的時候把安全放在首位。在理想的區(qū)塊鏈環(huán)境中，智能合約語言應(yīng)該好學(xué)也好用，但實際情況不可能如愿以償。我們知道，要成功完成經(jīng)典的程序演示“Hello world”，需要寫 150 行左右的代碼。代碼量如此之大，自然容易產(chǎn)生可能造成上百萬美元損失的 bug。

私有鏈和公鏈不會毫無關(guān)系

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

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

作者介紹：

Stuart Popejoy，涉足金融領(lǐng)域 15 年，在貿(mào)易系統(tǒng)和交易平臺框架創(chuàng)建方面擁有豐富經(jīng)驗。曾供職于美國摩根大通公司的新產(chǎn)品研發(fā)部，期間領(lǐng)導(dǎo)開發(fā)了摩根的區(qū)塊鏈主打產(chǎn)品——Juno。Stuart 還參與編寫了摩根的算法交易腳本，為日后 Kadena 簡潔特定的智能合約語言奠定了基礎(chǔ)。離開摩根后，與 Will Martino 在 2016 年聯(lián)合成立智能合約創(chuàng)企 Kadena，任公司總裁。