作者 | Stuart Popejoy
編譯 | 王國璽
出品 | 區塊鏈大本營（blockchain_camp）
自 Libra 釋出以來，沉寂已久的區塊鏈社羣又活躍了起來，一些探索區塊鏈業務的公司也在暗地裡較勁不甘落後。相信你也注意到了，這些大公司往往都對現有比特幣、以太坊等區塊鏈視而不見。這是因為它們深知資料的重要性，因而不會選用比特幣、以太坊這些把資料開源公開的公有區塊鏈，而是對可以控制參與者加入的私有區塊鏈情有獨鍾。
說到私有區塊鏈，就不得不提到 IBM。IBM 可謂是私有區塊鏈領域的領頭羊，其區塊鏈產品 Hyperledger Fabric 是許多區塊鏈開發人員的首選，同時 IBM 還與沃爾瑪、美國安泰保險金融集團這樣的大公司強強聯手，一起進行區塊鏈落地場景的探索，以在企業區塊鏈中搶佔先機，擴大優勢。推特上有人統計，僅在過去一年，IBM 區塊鏈專利的數量就增長了 300%。
作為開源非營利組織 Hyperledger 基金會的眾多貢獻者（其中包括最近加入的微軟以及客戶關係管理平臺 Salesforce）之一，IBM 可謂是花了血本來推動 Hyperledger Fabric 的發展，這意味著 Hyperledger Fabric 會有和比特幣、以太坊這些常見區塊鏈一樣的特性，同時會在其中刪除“並不適合企業場景”的特性。
雖然說 IBM 將 Hyperledger Fabric 稱為區塊鏈並以區塊鏈的名義來營銷，但無論是與許可區塊鏈相比還是與公有區塊鏈相比，Hyperledger Fabric 都犧牲了很多一個真正意義上的區塊鏈應有的特性。
雖然 Hyperledger Fabric 的架構遠比任何區塊鏈平臺複雜，但它在防篡改與防範攻擊等安全性特性方面依然做得不盡人意。你可能還會覺得“私有”區塊鏈至少能保證在可擴充套件性和效能上滿足需求，但 Hyperledger Fabric 的這兩個特性也會讓你失望。簡而言之，基於 Hyperledger Fabric 的實驗將面臨區塊鏈複雜且不安全的問題，同時區塊鏈的可拓展性可能也不能滿足業務快速增長帶來的需求。
對此，前摩根大通區塊鏈團隊領導人物 Stuart Popejoy 更是一針見血，聲稱 IBM 做了一個假的區塊鏈！
為什麼 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 中唯一一個重要的簽名就是驗證者的簽名，而使用者的簽名則消失在透過區塊鏈網路複製的任意資料庫中。
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）這些低階問題。程式碼越多，可能存在的漏洞就越多。
用 Hyperledger Fabric 編寫“ Hello World ”智慧合約
圖片來源： Chainhero 、Kadena
沒有為未來做好準備
在區塊鏈生態系統中，越來越多老道的觀察家都開始意識到私有區塊鏈和公有區塊鏈不可能完全隔離開來，而是會走向合作，相輔相成，共同促進：私有區塊鏈會希望自己的通證對公有區塊鏈上的客戶可用，部署在公有區塊鏈上的去中心化應用程式也會希望將隱私資料儲存在私有區塊鏈中。
很不幸，Hyperledger Fabric 以及 R3 Corda 都因為架構的完全不相容而與公有區塊鏈切割開來，這裡面也有智慧合約的責任，因為它們的智慧合約語言無法在公有區塊鏈和私有區塊鏈中無縫切換。
IBM 透過與其他大公司深入合作主導了許多企業區塊鏈的標準制定，但重要的是褪去表面的浮華去深入探索區塊鏈這項技術實際可以做些什麼。
IBM 所謂的“區塊鏈”技術在安全性、效能、可靠性等很多方面都存在缺陷，換句話說，IBM 為希望使用區塊鏈實現業務提升的企業提供了一個質量較差的解決方案。為更好實現區塊鏈的價值，老練的客戶將會選擇那些有著更好工具、區塊鏈效能更優、願景更好以及真正懂得如何使用這項技術的區塊鏈解決方案。
【宣告：文章僅代表個人觀點，其內容與觀點不代表區塊鏈大本營立場】
關於作者：
Stuart Popejoy 擁有15年的金融機構構建交易系統和資料交換骨幹網經驗。2016年 Stuart 與 Will Martino 共同創立了區塊鏈解決方案公司 Kadena 併成為公司總裁。在此之前，Stuart 曾在摩根大通集團的區塊鏈產品部門工作，期間領導和開發了摩根大通的主要區塊鏈產品 Juno，同時 Stuart 還為摩根大通編寫了許多交易演算法指令碼，這些經驗的積累幫助他在 Kadena 公司開發出簡單、定製化的智慧合約語言 Pact。
