阿裡妹導讀：區塊鍊技術，随着比特币的興起而為大家所知。但是具體到技術本身，大家相對熟悉的幾個詞可能是“資料不可篡改”、“公開鍊”、“分布式資料”、“共識機制”等。 這篇文章将抛磚引玉，通過深度解讀Hyperledger Project旗下的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項目大部分功能都無法通過可視化的配置，需要了解更多的底層細節才能正确搭建環境及配置。
引用
https://hyperledger-fabric.readthedocs.io/en/release/
https://github.com/hyperledger/fabric
https://www.ibm.com/blockchain/hyperledger.html
來源：阿裡技術
♥ 作者：明志健緻遠
♠ 出處：http://www.cnblogs.com/study-everyday/
♦ 本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接，否則保留追究法律責任的權利。
♣ 本部落格大多為學習筆記或讀書筆記，本文如對您有幫助，還請多推薦下此文，如有錯誤歡迎指正，互相學習，共同進步。