IBM 通過與其他大公司深入合作主導了許多企業區塊鏈的標準制定,但重要的是褪去表面的浮華去深入探索區塊鏈這項技術實際可以做些什麼。

原文標題:《「Hyperledger Fabric 是假區塊鏈!」》
作者:Stuart Popejoy,區塊鏈解決方案公司 Kadena 聯合創始人,推出智能合約語言 Pact,曾在摩根大通集團的區塊鏈產品部門工作,期間領導和開發了摩根大通的主要區塊鏈產品 Juno,同時爲摩根大通編寫了許多交易算法腳本
編譯:王國璽

自 Libra 發佈以來,沉寂已久的區塊鏈社區又活躍了起來,一些探索區塊鏈業務的公司也在暗地裏較勁不甘落後。相信你也注意到了,這些大公司往往都對現有比特幣、以太坊等區塊鏈視而不見。這是因爲它們深知數據的重要性,因而不會選用比特幣、以太坊這些把數據開源公開的公有區塊鏈,而是對可以控制參與者加入的私有區塊鏈情有獨鍾。

說到私有區塊鏈,就不得不提到 IBM。IBM 可謂是私有區塊鏈領域的領頭羊,其區塊鏈產品 Hyperledger Fabric 是許多區塊鏈開發人員的首選,同時 IBM 還與沃爾瑪、美國安泰保險金融集團這樣的大公司強強聯手,一起進行區塊鏈落地場景的探索,以在企業區塊鏈中搶佔先機,擴大優勢。推特上有人統計,僅在過去一年,IBM 區塊鏈專利的數量就增長了 300%。

作爲開源非營利組織 Hyperledger 基金會的衆多貢獻者(其中包括最近加入的微軟以及客戶關係管理平臺 Salesforce)之一,IBM 可謂是花了血本來推動 Hyperledger Fabric 的發展,這意味着 Hyperledger Fabric 會有和比特幣、以太坊這些常見區塊鏈一樣的特性,同時會在其中刪除「並不適合企業場景」的特性。

IBM 的區塊鏈方案是假區塊鏈?細數 Hyperledger Fabric 的特性缺陷

雖然說 IBM 將 Hyperledger Fabric 稱爲區塊鏈並以區塊鏈的名義來營銷,但無論是與許可區塊鏈相比還是與公有區塊鏈相比,Hyperledger Fabric 都犧牲了很多一個真正意義上的區塊鏈應有的特性。

雖然 Hyperledger Fabric 的架構遠比任何區塊鏈平臺複雜,但它在防篡改與防範攻擊等安全性特性方面依然做得不盡人意。你可能還會覺得「私有」區塊鏈至少能保證在可擴展性和性能上滿足需求,但 Hyperledger Fabric 的這兩個特性也會讓你失望。簡而言之,基於 Hyperledger Fabric 的實驗將面臨區塊鏈複雜且不安全的問題,同時區塊鏈的可拓展性可能也不能滿足業務快速增長帶來的需求。

對此,前摩根大通區塊鏈團隊領導人物 Stuart Popejoy 更是一針見血,聲稱 IBM 做了一個假的區塊鏈!

Hyperledger Fabric 性能指標具有誤導性

2016 年我在摩根大通工作時,我領導了一個專攻前沿技術的團隊,來研究區塊鏈在銀行業中的潛在應用以及對區塊鏈的戰略投資。作爲工作的一部分,我們深入分析了早期版本的 Hyperledger、Axoni、Symbiont、Ripple 以及以太坊。當時很明確的一點是,市場上的幾個區塊鏈項目從技術上來說都不適合真實的企業場景。不幸的是,時至今日 Hyperledger Fabric 還是沒有解決這個核心問題。當時我們考慮到的細節包括:

  • 區塊鏈的智能合約語言如何安全、簡單地表達出複雜的業務邏輯?
  • 如何保證公鑰簽名的有效性?
  • 區塊鏈是否可以在不大幅度降低性能的前提下加入其他的參與者(節點),從而實現可拓展性?
  • 那些目光長遠的企業還會考慮到被選擇的區塊鏈將來能否可以輕鬆地與其他公有區塊鏈或私有區塊鏈進行互操作?

從這幾個細節入手分析,我認爲 IBM 的 Hyperledger Fabric 從根本上缺乏區塊鏈的必要元素,其性能指標充滿了誤導性,在長期業務上的可行性也不禁讓人打一個大大的問號。

我們從來沒有將 TPS、節點數這些忽悠外行人的數字遊戲看作是區塊鏈的採用標準,但在經歷多了這些數字遊戲之後我們認爲有必要告訴讀者什麼是區塊鏈,而什麼不是區塊鏈。

什麼是區塊鏈?什麼不是區塊鏈?

爲更好地理解 IBM 區塊鏈的定位,我們需要回到區塊鏈的定義。區塊鏈的核心是一個去中心化的不可篡改的賬本,賬本中存儲着事件或者交易,而往賬本中加入哪些數據完全由共識機制來決定。在比特幣和以太坊這樣的公有區塊鏈中,這種共識是通過工作量證明或稱「挖礦」來實現的。在許可區塊鏈中,參與者提供密碼學簽名來對共識的內容進行投票,從而達成共識。無論是哪種方式,都不會有中央機構進行干預。

而 IBM 對區塊鏈的定義延續了去中心化和不可篡改這兩個區塊鏈的元素,但它爲了方便省去了去中心化的共識機制,從某種程度上來說,Hyperledger Fabric 根本不需要一個真正的共識機制。相反,Hyperledger Fabric 推薦使用一個名爲 Kafka 的「訂購服務」。

但問題是,如果沒有基於密碼學算法的強制執行、沒有高度的民主化、沒有密碼學機制保證參與者投票的安全,那麼你就不能證明是否有人篡改了區塊鏈這個賬本。帶有容錯機制的共識是區塊鏈的標誌性特徵,少了它,IBM 的「區塊鏈」只不過是一個帶時間戳的項目列表。

Hyperledger Fabric 的體系架構暴露出許多可能會被惡意參與者利用的漏洞。就比如說,它在「網絡內部」引入了公鑰加密機制和驗證者簽名,但是這些主要的安全保證只有在提交了外部簽名的交易之後才產生。

這從根本上廢除了比特幣以及其他區塊鏈久經時間驗證的安全模型,其中任何交易的來源僅由外部用戶的公鑰簽名來保證,並且系統不能以任何方式進行干涉。

與之形成鮮明對比的是,Hyperledger Fabric 中唯一一個重要的簽名就是驗證者的簽名,而用戶的簽名則消失在通過區塊鏈網絡複製的任意數據庫中。

IBM 的區塊鏈方案是假區塊鏈?細數 Hyperledger Fabric 的特性缺陷Hyperledger Fabric 1.0 交易生命週期,圖片來源:developer.ibm.com

在 Hyperledger Fabric 所提供 API 的幫助下,向區塊鏈中加入一筆交易要經過如下步驟:

一筆交易預提案被提交後,由背書節點( endorsing peer )通過智能合約語言 chaincode 執行它的邏輯,同時它會查詢狀態數據庫並生成要使用到的讀寫集( REset),之後它還會連同生成的讀寫集返回交易預提案的迴應。接下來,系統會將帶有讀寫集的交易預提案提交。訂購服務會把一批次的交易加入到區塊中。所有的節點都會收到訂購服務發來的區塊信息,但它們需要驗證區塊中的交易信息來保證區塊鏈中數據的安全性,步驟如下:

  1. 驗證背書節點的執行策略;
  2. 驗證當前狀態數據庫中讀寫集的版本;
  3. 向區塊鏈中提交區塊信息;
  4. 向狀態數據庫中提交已驗證過的交易信息。

Hyperledger Fabric 的研究人員不遺餘力地玩這些數字遊戲,在所謂的性能指標上做文章,因爲從根本上來說 Hyperledger Fabric 的架構根本無法在保持最佳性能的同時進行擴展。Hyperledger Fabric 使用一個多鏈環境(被稱爲「通道 channels」)來保證參與者之間的隱私性。這種隱私性是私有「企業」區塊鏈的一個重要特性,但它必然會帶來一些折衷,也會大大增加區塊鏈的複雜性。

但從企業區塊鏈需要的可拓展性方面來說,多鏈解決方案並不是一個好的選擇,因爲這樣做會使得部署過程太過於複雜、節點分佈不均勻、智能合約不可靠、還會大大增加潛在的故障點。

因此,Hyperledger Fabric 區塊鏈在部署之後的性能指標並不盡如人意,隨着節點的增加性能還會迅速下降,而且它所宣稱的性能是單通道時的性能:如果你想跨過多個通道與整個區塊鏈網絡進行交互,這些所謂的性能指標沒有任何意義

即便如此,對於每個獨立的通道,區塊鏈的每秒處理交易量很難突破 800 這個大關,但即使是擁有 16 個通道配置的區塊鏈也幾乎不能達到 1500TPS,若區塊鏈一直維持吞吐量上限運行,其延遲時間可能會達到 10 到 20 秒。

最近一些旨在加快 Hyperledger Fabric 運行速度的研究使得其每秒處理交易量能達到驚人的 20000,但性能大幅度提升的背後是研究人員對 Hyperledger Fabric 架構的大規模「魔改」,這使得 Hyperledger Fabric 已經成一個近似的區塊鏈變成了一個四不像:背書節點(Endorsers)不再充當驗證者而 Kafka 被認定爲唯一可行的訂購服務。最後,這些仍然只是單通道的性能,這意味着它與區塊鏈作爲共享可信來源的整個理念相違背。

注:從理論上講,Hyperledger Fabric 可以使用真正意義上的區塊鏈共識,但這樣做區塊鏈會變得很慢,而在生產環境中慢是致命的,因此沒有人會在生產環境中使用它。

爲什麼說智能合約很重要?

我們在評價區塊鏈時,最後一個考慮因素是區塊鏈準備如何擴展私有數據庫,以及區塊鏈的工具(比如,智能合約語言)如何在企業業務規模飛速發展時不掉鏈子。需要注意的是,智能合約不僅僅是一段代碼,它是公司業務邏輯的體現。智能合約可以執行區塊鏈上的產權登記,數字身份的驗證,甚至可以用來執行二手車買方和賣方之間的託管交易。最重要的是,智能合約是可靠的,它始終會按照你給它的規定行事。

在區塊鏈上構建業務邏輯時,你需要將自己想要進行的操作(買入、賣出、打包數據等等)用智能合約表示出來。如果智能合約語言使用起來簡單而又方便,你就能快速地構建出想要的業務邏輯向你的老闆或股東交差。更重要的是,你肯定會希望智能合約的功能十分強大,能夠爲你的業務帶來收益或一些積極的影響。

Hyperledger Fabric 的智能合約(稱爲鏈碼「Chaincode」)可以用多種編程語言編寫,其中包括常見的 Javascript 語言以及 Go 語言。但使用開發人員十分了解的通用編程語言開發是一把雙刃劍,它在大大簡化開發過程的同時,在安全性方面與專爲區塊鏈開發的編程語言相比大大弱化。如果 Hyperledger Fabric 中累積的權益越來越多,總會有人鋌而走險。

在這時如果代碼有缺陷或不正確(因爲它不是專爲區塊鏈設計的)那麼可能會造成數百萬美元的損失。因此我們認爲智能合約語言必須專爲區塊鏈設計且爲安全性做出了優化。在理想的情況下,智能合約語言也應該易於學習,並能便捷地在區塊鏈環境中使用。

Chaincode 在這幾個方面可謂是徹徹底底地失敗了,我們發現被譽爲開發人員的第一個程序 「Hello World」 在其他語言中僅需幾行就可以實現,而在 Chaincode 中居然需要 150 行之多。代碼越多,可能存在的漏洞就越多。這麼大數量的代碼中可能隱藏着很多能造成數百萬美元損失的漏洞。

編寫以及閱讀智能合約本不應該如此困難。開發人員不得不處理調度(dispatch)、實參發現(arqument discovery)這些低級問題。代碼越多,可能存在的漏洞就越多。

IBM 的區塊鏈方案是假區塊鏈?細數 Hyperledger Fabric 的特性缺陷用 Hyperledger Fabric 編寫「 Hello World 」智能合約,圖片來源:Chainhero 、Kadena

沒有爲未來做好準備

在區塊鏈生態系統中,越來越多老道的觀察家都開始意識到私有區塊鏈和公有區塊鏈不可能完全隔離開來,而是會走向合作,相輔相成,共同促進:私有區塊鏈會希望自己的通證對公有區塊鏈上的客戶可用,部署在公有區塊鏈上的去中心化應用程序也會希望將隱私數據存儲在私有區塊鏈中。

很不幸,Hyperledger Fabric 以及 R3 Corda 都因爲架構的完全不兼容而與公有區塊鏈切割開來,這裏面也有智能合約的責任,因爲它們的智能合約語言無法在公有區塊鏈和私有區塊鏈中無縫切換。

IBM 通過與其他大公司深入合作主導了許多企業區塊鏈的標準制定,但重要的是褪去表面的浮華去深入探索區塊鏈這項技術實際可以做些什麼。

IBM 所謂的「區塊鏈」技術在安全性、性能、可靠性等很多方面都存在缺陷,換句話說,IBM 爲希望使用區塊鏈實現業務提升的企業提供了一個質量較差的解決方案。爲更好實現區塊鏈的價值,老練的客戶將會選擇那些有着更好工具、區塊鏈性能更優、願景更好以及真正懂得如何使用這項技術的區塊鏈解決方案。

來源鏈接:mp.weixin.qq.com