前摩根大通研發:為什麼 IBM 區塊鏈不是真正的區塊鏈?
By 區塊鏈前哨·
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,任公司總裁。原文連結:https://medium.com/@mikeycrypto752/why-ibms-blockchain-isn-t-a-real-blockchain-7dbe820751ee#IBM#IBM區塊鏈#區塊鏈技術
免責聲明:
- 本文版權歸原作者所有,僅代表作者本人觀點,不代表鏈報觀點或立場。
- 如發現文章、圖片等侵權行爲,侵權責任將由作者本人承擔。
- 鏈報僅提供相關項目信息,不構成任何投資建議。
推荐阅读