如何用區塊鏈技術解決信任問題？Fabric 架構深度解讀

來自專欄 我是程序員

摘要： 前言 Hyperledger Project 由Linux基金會創辦於2015年10月，是一個開源的區塊鏈研發孵化項目，致力於提供可協同開發以區塊鏈為底層的分散式賬本。旗下的Fabric項目目標為打造一個提供分散式賬本解決方案的平台。

前言

Hyperledger Project 由Linux基金會創辦於2015年10月，是一個開源的區塊鏈研發孵化項目，致力於提供可協同開發以區塊鏈為底層的分散式賬本。旗下的Fabric項目目標為打造一個提供分散式賬本解決方案的平台。

業務上所期望解決的問題——信用問題

首先從比特幣說起，大家對比特幣算力證明（POW）的名詞應該不陌生，先不說其耗費大量的資源，從共識機制上來看，擁有超過50%的算力即可掌控整個比特幣，無論從技術還是業務的角度都是一個風險極高的機制，但神奇的金融圈沒有人會去觸碰這樣的底線，一旦有人擁有超過50%的算力，比特幣可能就玩不下去了：）

那麼實際的業務場景中的需求應該是怎樣的呢？比如說，銀行結算清算系統，傳統的銀行交易系統中，如果出現跨行交易，那麼交易數據便需要一個清算系統進行定時對賬確保雙方的交易數據是同步無誤的，那麼就可能導致跨行轉賬需要T+1的時長，而主要的原因是因為雙方的系統及數據相互獨立，數據互不「信任」，所以需要一個清算系統去驗證交易數據，而區塊鏈可以說是為了解決這種「信任」問題而產生的技術，在雙方進行交易的同時對數據進行了認證，那麼便無需交易後再進行清算而達到實時轉賬等功能。下面來說為了解決「信用」問題，技術上需要哪些手段去滿足。

技術上需要哪些特性去達到「數據可信任」

以上面提出的清算系統為例，可能有人提出，雙方使用同一個分散式資料庫不就可以達到實時的數據同步了嘛。確實，區塊鏈其中一個特性便是分散式，但是和傳統的分散式資料庫區別在哪呢？在回歸到業務中，如果雙方銀行進行交易的時候，使用這樣一個分散式資料庫，難道不擔心對方偷偷地把數據改了嗎？如果你說有日誌可以追述得到修改記錄，首先日誌也是容易被修改的，且日誌也無法挽回動不動可能就上百萬千萬甚至過億的金額損失，所以說傳統的分散式資料庫對於企業之間來說是」不可信的「，那麼便要求區塊鏈需要達到數據不可篡改、用戶有身份認證、交易可追述、交易有權重等一系列的特性。

剖析技術原理

上面說到區塊鏈的各種特性，從功能上來說這些特性有些是相輔相成。那麼應當如何去實現這些功能呢，接下來結合Fabric的一些具體實現來一一闡述。

存儲數據結構

要達到數據不可篡改首先從數據結構上來看，也是區塊鏈之所以稱之為區塊鏈的原因。如下圖所示，每個存儲單元包含上一存儲單元的hash值（圖中hash值的對應關係不完全精確，僅示意用）以及自身存儲的交易數據塊，可以從表象來看就像把所有數據塊連接在一起，稱之為「區塊鏈」，形成鏈狀可追述的交易記錄。這種鏈狀結構的數據稱之為賬本數據，保存著所有交易的記錄，此外還有一個「世界狀態」，其實質為Key-Value資料庫，維護著交易數據的最終狀態，便於查詢等操作運算，並且每個數據都有其對應的版本號。

Fabric主要模塊

總體來說，市面上各種區塊鏈的實現方案都是基於這種數據結構，而僅靠數據結構並不能保證數據不可篡改，還有一個非常重要的因素，便是共識機制，一個好的共識機制才是保障整個業務運轉的根本，相當於雙方簽訂的合同或者協議，只有雙方都遵守條約才能合作將業務展開進行。例如常見的POW，POS，PBFT等都屬於共識機制，而其原理或者弊端這裡不做贅述，主要來詳細講解Fabric應用的設計方案及其原理，此前先解釋下一些特定名詞的概念。

首先說」智能合約「的概念。在傳統中心化的系統中，例如支付寶用戶A給B轉賬100元，那麼假設起始A有100元B有0元，那麼在支付寶系統內調用轉賬的函數可能是這樣的一個流程，調用transfer(A,B,100)，而函數內可能會去讀取用戶A和B的賬戶餘額，那麼我們可以表達成input(A,B,100),read(A:100,B:0),write(A:0,B:100)，那麼這個僅是在支付寶的系統內執行了便完成了，那如何形成一個合約呢？

就如A、B在簽訂一份合同，雙方都要對合同進行簽名認可，在程序中就等於，用戶A在其本地執行transfer(A,B,100)得出input(A,B,100),read(A:100,B:0),write(A:0,B:100)並對其簽名認證，用戶B在其本地執行transfer(A,B,100)得出input(A,B,100),read(A:100,B:0),write(A:0,B:100)並對其簽名認證，然後雙方將結果發給對方，然後判斷對方結果是否一致並對其簽名進行校驗無誤後便認為合約達成將結果寫入本地。通俗來說就是將一段核心代碼抽出來，所有參與方都去執行該代碼並對其結果進行簽名認證比對，便稱之為執行智能合約，而其中共有的代碼便是「合約"。

再說」背書策略「的概念。那麼根據上面所言的共有代碼在交易中是不是所有用戶都要執行呢？比如說A、B用戶轉賬，那麼C、D用戶顯然就不需要規定其參與執行職能合約了，那麼背書策略便是規定智能合約的結果需要哪些成員的簽名背書才算交易成功。

在Fabric的交易流程中，主要有幾個關鍵節點參與，包括Peer節點、Orderer節點、CA節點及client端。

• Peer節點

該節點是參與交易的主體，可以說是代表每個參與到鏈上的成員，他負責儲存完整的賬本數據即區塊鏈數據，負責共識環節中的執行智能合約，其中所有的Peer節點都維護完整的賬本數據稱之為Committer，而根據具體的業務劃分背書策略時決定哪些Peer。

• Orderer節點

該節點負責收集交易請求進行排序並打包生產新的區塊，主體功能便是對交易排序從而保證各Peer節點上的數據一致性，也包含了ACL進行訪問控制。

• CA節點

該節點負責對加入鏈內的所有節點進行授權認證，包括上層的client端，每一個節點都有其頒發的證書用於交易流程中的身份識別。

• client

Fabric對於client端提供了SDK讓開發人員可以更容易地對接到區塊鏈內的交易環節，交易的發起便是通過SDK進行。

供應鏈金融中的應用

以上簡單的闡述了各模塊的功能，當然實際當中包含更多服務支持的功能，那麼這裡在套進供應鏈金融來舉例，更好地理解各節點的意義。

一個簡單的供應鏈模型，一個核心企業向其供應商進行採購1000w物資，按照賒銷合同在收到物資後半年進行結賬，那麼半年的賬期供應商資金無法周轉開便拿著核心企業開具的銀行承兌匯票進行抵押融資，那麼銀行審核通過後將票據95%的金額馬上轉給了供應商，半年賬期到後，核心企業便直接將貨款轉給銀行，這樣就形成了一次供應鏈的融資交易了。

在實際的業務當中大部分都是在線下進行操作的，耗費眾多的人力及時間，那如何將這樣的業務轉成線上電子化呢？有人或許說銀行提供這樣的平台服務不就好了嘛，那假設這個平台不僅僅是這一家銀行參與呢，若所有的銀行或者企業都可以在同一個平台進行，那麼交由某一個銀行提供服務就顯得不合適了。好，那麼我們用Fabric來實現這樣一個系統我們看看在部署上是怎樣分布的呢。

上面是理想下的模型，當然在實際當中這樣的部署方案也可能不成立，比如供應商並不一定有能力在其內部接入伺服器等。我們仍然以此為例說明節點的意義，圖中每個參與方都在本地部署Peer節點以及接入業務系統client端，那麼每個Peer節點都保持了所有交易的數據，那麼在查數據的時候僅在本地便可完成，當然也可以去查他人的Peer節點比對數據，而中心的CA節點負責給每一個節點包括client端頒發證書讓其在交易流程中可以互相認證從而防止外部惡意接入查看數據或者參與交易，而Orderer節點與所有的Peer節點相連接獲取交易結果進行排序控制，那麼這裡涉及到了整體的交易流程，引用官方的示例圖來解釋。

來描述一下上圖的交易流程，首先由client發起一個交易請求，而上圖中的背書策略要求Peer1、Peer2及Peer3參與交易，所以client將請求分別發給Peer1、Peer2和Peer3，然後三個Peer接收到交易請求後執行對應的智能合約並對結果進行簽名然後分別將輸出結果返回給client，client收到所有執行結果後打包一併發送到Orderer，Orderer將接收到的該次交易在交易池裡進行排序並組合打包生成一個新的區塊，Orderer將新的區塊發送給所有的Peer節點，每個Peer節點接收到新區塊後，對其中的每一筆交易結果的簽名進行驗證是否符合背書策略，以及比對讀寫集合（Read-Write Set，在下面的章節中解釋）與本地的版本是否相同，如滿足所有條件則將新的區塊寫入本地賬本內完成交易。

以上是相對粗略的描述了交易流程，而實際當中還有很多細節的處理。除此外可能有人會問，共識節點去哪了？為什麼有Orderer這樣的中心節點？如果再細細思考一下，你會發現共識機制已經融合在整個交易流程中了，這也是這個設計優越的所在，我們來分析一下，假設Orderer節點是惡意節點，是否能控制交易生成」假賬「呢？那麼再來看一下Orderer的功能，接收交易數據進行排序並打包成塊，假設Orderer要造假數據，那麼他需要繞過的是每個Peer節點將數據寫入前進行的背書策略的校驗，那麼數據里就必須包含背書策略里要求的節點簽名，而Orderer是沒有辦法獲取到各Peer節點的私鑰也就沒辦法生成對應的簽名，由此Orderer是沒辦法控制交易鏈造假的，可以說Orderer是一個工具服務並不參與到任何業務流程內，其關心的只是服務的穩定性，如果需要數據對Orderer節點保密，目前需要自行實現數據加密。正因為其背書策略的設定，可以精確地滿足的具體的業務場景需求不會受到任何形式的惡意節點入侵，這也是區別於POW或者拜占庭容錯等，他們在一定條件後是可能被惡意節點所操控的。

核心基礎服務

對Fabric的主體模塊及流程有一定認識後，我們在繼續深究裡面的細節功能，為了讓整個框架能運作起來當然需要用到更多的技術手段，這裡主要講幾個相對核心的功能點。

• Gossip Protocol

回顧上述的交易流程圖中，Orderer將交易數據排序打包後分發給各個Peer節點，若假設有成百上千甚至更多的Peer節點都由Orderer節點進行分發那麼首先單點的壓力是否能承受，其次如果出現失敗的情況又該如何同步等問題。在Fabric的實現當中，採用的是讓Peer節點之間相互同步而非Orderer節點來分發消息，每個Peer節點都會維護其他Peer節點的信息，隨機的與部分其他Peer節點進行通信互換區塊信息，傳輸時利用Peer-to-Peer的技術去加快數據的傳輸，而Orderer節點僅是將打包好的區塊發送至特定的Leader Peer（可手動指定也可由Orderer自行選取），然後Peer節點之間在通過Gossip協議相互交換數據達到最終一致性。

• Eventhub

那麼根據上面描述的Gossip協議，可見每個Peer節點寫入區塊的時間可能是不一致的，那麼client端進行業務邏輯判斷（如事務邏輯）如何獲知特定交易數據是否已經寫入Peer節點內呢？實際上每個Peer都會和client端保持一個Eventhub的連接，在Peer節點完成交易後，如將區塊寫入賬本後便會發送消息通知各個client，但是也要注意，回調總是不可信的，存在消息丟失的可能性，Fabric也並沒有保證消息的最終到達。

• Read-Write Set

在Peer節點將一個區塊寫入賬本前，如上所述會進行背書策略的校驗，以防止惡意節點的入侵，達到有權重劃分，可實名制交易的聯盟鏈。除去驗證各節點簽名驗證，當然還要比對個節點輸出的結果是否一致，那如何去衡量結果是否一致呢？這裡提出了讀寫集合的概念，一段程序我們化做為IO，如果使用相同Input得出一致的Output，那麼我們便可以認同在這一特定情況下函數性質是相同的。在這裡我們並不關心Input，只要寫入/修改的數據一致便可認為達成了共識，所以Write Set是用於保存最終需要寫入/修改的數據集，這個是用來比對各節點的結果集是否一致，而Read Set中存著各節點執行合約中讀取了哪些數據，並會把這個數據的當前版本記錄在Read Set中，在Peer節點寫入區塊前也會校驗Read Set中讀取的數據版本是否和當前數據環境中的版本一致，以防止交易並髮帶來的錯亂。

認證體系

剛接觸區塊鏈的同學可能會有一個概念，區塊鏈應該保證公平公正公開，所以形成了「公有鏈」的一個概念，例如比特幣，全員可參與，對所有人透明。但是區塊鏈並不僅局限於「公有鏈」，對於大多數業務場景來說，應該屬於「聯盟鏈」，即由特定成員參與、有權重分配的業務，例如銀行間的對賬環節，A、B、C銀行互相的交易中，A、B銀行間的交易當然不願意透露給C銀行，而A、B、C銀行的所有交易或許都要上報給央行，可見此處「公有鏈」是不可取的。那如何去保證公平公正公開呢？首先代碼必須對成員開源，所有服務可由自身搭建，利益相關成員共同審核「智能合約」，全員共識的背書策略，相互授權或由可信第三方認證中心授權。那麼最基礎的一道認證體系便顯得尤為重要了，我們在來看看Fabric是如何去實現他的認證體系的。

首先有幾個概念需要明確，Fabric的CA認證中心是基於PKI體系打造的，相關資料可參考如下。

• PKI(Public Key Infrastructure)
• X.509 證書

Membership Service Providers(MSP)

在劃分成員結構的時候Fabric用MSP來定義一個成員，在最佳實例推薦中，一個企業或者機構可以是一個單獨的MSP，例如上述說到的供應鏈的案例，由例圖來說明，核心企業便是一個MSP，銀行和供應商各代表一個MSP，那麼在一個MSP下可以有多個Peer節點，而不同的授權便有不同的功能，MSP具體應用場景主要如下。

• 在部署智能合約或者初始化時需要擁有對應CA賦權的證書才可執行（默認為PeerAdmin用戶）。
• 為新節點或用戶註冊證書時，需要CA對該操作證書賦予許可權（一般為Admin用戶）。
• 在背書策略中可通過MSP來代表背書成員，可設定單個Peer節點代表其MSP達成協議（也可以要求全部Peer節點通過才達成協議）。
• 在跨MSP間的Peer節點通信，先通過各MSP內指定的Anchor Peer收集MSP內的Peer列表，然後通過各MSP下的Anchor Peer交互其Peer列表，將其他MSP下的Peer列表同步到內部Peer後，便通過Gossip協議Peer節點間隨機通信。
• 每個MSP都有自己獨立的CA節點，為其提供所有的證書需求，各MSP共享其CA節點的ROOT證書達到互相認證。
• 匿名交易。在一筆交易中，包含著每一個參與背書的用戶證書，這可以認為是公開實名制的交易，所有鏈內成員都可以看見每一筆交易是由誰參與的，但是如果我們希望匿名交易該如何實現呢？在Fabric 0.6版本內有Ecert和Tcert的概念，Ecert即為用戶的證書，而Tcert則是用於匿名交易，用戶可以通過向CA申請一批Tcert用於交易，而該Tcert不包含用戶的信息，當需要驗證查驗信息時可通過CA來認證該用戶的身份。（此功能在1.0版本尚未實現）
• Revoke，廢除證書。在PKI體系中，其最大的優勢便是Off line的，即在證書頒發後，不需要CA節點的存在也可以在本地進行認證，而遇到很大的問題是類似於廢除證書時如果希望能即是將廢除證書的消息通知到各個節點，目前的做法是需要CA節點保持在線並與各節點保持通信。（獲取Tcert也需要CA節點在線）

在每個區塊鏈中其相關的配置信息也包含了MSP的劃分，闡述相對複雜這裡便不描述，有興趣可以參考官方文檔 ：）

難點及待解決的問題

上述篇幅主要是給讀者對Fabric的整體框架有基本的認識，仍有許多細微的問題無法一一討論。當然，在區塊鏈尚未大規模能應用於市場下其技術也是不完善的，在Fabric中也有許多需要解決的難點問題。

在官方推薦的實踐當中，劃分數據的隔離是通過賬本的粒度進行隔離，不關聯的交易便在不同的賬本中了，但是實際業務當中，總有需要在單賬本內進行數據隔離的場景，早前已經看到有相關的設計文檔出稿了，不過距離正式發布該功能就不確定合適能完成了，目前只能自行在業務邏輯中對數據進行加密隔離。

當兩個數據通過賬本隔離後需要交互的場景目前來看是比較難實現的，及跨賬本調用，首要解決的問題便是認證模型如何去進行融合。

目前想要接入區塊鏈的成本仍然是很高的，即便Fabric項目大部分功能都無法通過可視化的配置，需要了解更多的底層細節才能正確搭建環境及配置。

原文鏈接

原文發布時間為：2018-04-10

本文作者：楓爺

本文來自雲棲社區合作夥伴「阿里技術」

更多技術乾貨敬請關注云棲社區知乎機構號：阿里云云棲社區 - 知乎