Fabric的區塊鏈協議調研報告
關於Fabric的基本介紹這裏就不贅述，報告主要從Fabric設計的整體邏輯架構開始，重點講述涉及區塊鏈服務設計的核心內容。下面是Fabric的邏輯架構：
可以看到Fabric主要由成員服務（Membership Services）、區塊鏈服務（Blockchain Services)、和鏈碼服務（Chaincode Services）三個服務板塊組成。Fabric有着突出的四大功能：身份管理、隱私與保密、高效處理、鏈碼功能，這其中身份管理就是很重要的一個特色，也就是成員服務（Membership Services）這一板塊，它通過對參與者進行身份的審覈，進而確保平臺的安全性和權限管理，但是這一塊與鏈的關係不是很直接，我們放到最後作爲補充；同時鏈碼功能（Chaincode Services）與智能合約幾乎等價，我們也是放到最後再講，重點放到中間的這一層區塊鏈服務（Blockchain Services）。
區塊鏈服務
區塊鏈服務（Blockchain Services）負責了節點的共識管理、賬本的分佈式計算、賬本的存儲以及節點間的P2P協議功能實現。下面先從節點開始，進而深入探究Fabric的交易流程以及共識機制：
節點：
在Fabric中，出現得最多的就是對等節點（peer node），它是鏈的基本元素，類似於其他區塊鏈上的普通節點，下面是它的基本結構圖：
每一個對等節點都可以存放賬本和鏈碼（這裏的鏈碼與我們所說的智能合約基本是一樣的），當然每一個節點可以存放多個賬本，也可以存放多個鏈碼，節點可以創建也可以刪除。對於最簡單的交互訪問賬本模型可以從下面的結構圖分析：
查詢操作：
A是作爲應用程序對節點進行各種操作（如訪問查詢等），在上面的這一個結構流程圖是表示了應用程序A連接到對等節點，通過調用對等節點的鏈碼S1進行查詢或者更新它的賬本L1，對於更新賬本這個操作，我們後面會進行更進一步的分析，因爲更新賬本一般不是一個對等節點自己就可以決定的事情，我們假設這是一個查詢操作，（因爲查詢不需要諮詢其他節點），對等節點把查詢到的結果返回給應用程序，經過這個流程，這是有另外一種節點，我們叫做排序節點，來對事件進行打包成塊，發送給所有網絡節點，P1在處理好這個交易後產生一個相應事件給應用程序A。
更新操作：
上述是不用其他節點共識的簡單查詢，如果是要更新事務，單個節點不能私自更新賬本，需要徵求其他節點的驗證的，就涉及到共識機制，這裏涉及三個流程：
提案
對於應用程序A1想要提出一個交易提案，需要對等節點P1和P2進行執行並確認，它首先發起分別對於這兩個節點的交易提議，節點對收到的事務生成響應並且帶上確認，例如對於節點P1，它通過執行鏈碼生成R1響應並且帶上自己的E1確認。PS：在這裏面，賬單更新選中的節點是由政策定義的鏈碼決定的，在這個例子中該交易需要P1和P2進行操作確認。這個階段在應用程序收到足夠多的簽名響應時結束。接下來就是進行打包；
打包
在鏈上的節點除了對等節點，還有排序節點，這些節點的作用就是打包更新賬本提案，例如對於剛纔上面所說的程序A1接收到的兩個節點P1和P2返回的驗證事務，就是需要提交給排序節點O1，排序節點把這個事務按照一定的順序與其他類似的交易事務打包進區塊，至於順序不一定是按照時間先後，但是這個順序是固定的，不管用什麼方式，這使得事務一旦被寫到數據塊上，那麼永遠都不會改變，也就是不會發生賬本分叉。這個過程就是簡單的收集打包，沒有任何的驗證，它不需要對交易價值進行判斷，只是機械地不可逆打包。
驗證
在上面打包得到的塊需要發佈到對等節點，如下：
排序節點把打包後的區塊發佈給了P1、P2，節點通過處理這個區塊進行自己賬本的更新，並且會通知其他節點這個交易已經處理。當然這個處理是有一定認可政策的，例如這個提案交易需要多少人同意認可纔是有效，如果驗證成功，對等節點的賬本將更新，而失敗的驗證交易將不會更新於賬本。最終節點也會返回響應事件給應用程序作爲響應。
整體來看，所有的對等節點在排序節點的協同下，達成了交易順序以及內容的一致性，而對於節點的類型，大家可能有疑問，主要分爲：提交節點、背書節點、領導節點、錨節點。其實每一個對等節點都是一個提交節點，可以接受交易區塊並更新，也都可以有智能合約，可以執行並驗證，成爲背書節點，當然還有排序節點對交易進行打包成塊，而領導節點可以對打包好的交易分發給組織中的其他節點。錨節點則是作爲一個節點與其他組織節點通信的節點。因此交易流程一般分爲：應用程序發佈提案給背書節點進行驗證，背書節點執行並簽名，應用程序收集交易併發送給排序節點，排序節點打包並廣播，接收到的節點驗證並寫入賬本。
共識服務
剛剛談到的排序節點，這些節點就是整個系統共識機制的維護者，它相當於提供了一個交付保證的通信組織，爲客戶端以及對等節點之間提供了一個共享的通信通道，同時提供廣播服務。在Fabric中，這樣的共識服務是可插拔模塊，目前有主要三種模式，Solo、Kafka、BFT。Solo是一種部署在單個節點的時序服務，只能支持單鏈；而Kafka能夠容忍部分節點宕機失效，但是不能容忍惡意節點，BFT則是我們很熟悉的拜占庭，n>=3f+1則有效。
分佈式賬本結構
在區塊鏈上，賬本存儲了所有歷史交易和狀態改變記錄，在Fabric中，每一個通道中都有一個共享賬本，賬本的結構如下：
可以看到每一個節點維護的賬本以文件系統的形式存儲於本地，主要是四個數據庫，包括賬本索引庫（快速查詢賬本）、區塊索引庫（快速查詢區塊和交易）、狀態數據庫、歷史數據庫，狀態數據記錄的是交易執行的結果，記錄的是所有變量鍵值的最新值，也叫作“世界狀態”；歷史數據記錄了每一個狀態數據的歷史信息，可以用於區塊提交的回覆。一般的交易記錄分爲，保存到賬本數據中、更新狀態數據、更新歷史信息數據。
網絡模型
對於Fabric的網絡環境可以參考下面：
對於這個網絡，我們可以看到有四個企業R1、R2、R3、R4被寫入一個網絡協議中，R4是這個網絡的發起者，它也沒有任何打算與企業進行交易，整個網絡間，R1與R2有私自聯繫的需求，R2和R3也是，企業R1有一個客戶端應用可以通過通道C1進行交易，R2則可以在通道C1和C2進行交易，R3與R2類似。對於節點1維持了一個賬本L1的副本與通道C1聯繫起來，節點2維持了一個賬本L1與C1聯繫、一個L2與C2聯繫。有一個訂購服務O4爲節點提供服務並且利用系統的通道，用於將塊分發。
通道
在上面提到的通道是Fabric的一個特色，它是在兩個或者多個成員之間專門爲私人的和機密的交易爲目的而建立的私有“子網”，正如上面我們所說到的每一個交易都在一個指定的通道中執行，在通道中交易必須通過通道中的每部分認證和授權，要加入一個通道都必須有成員服務提供商獲得的身份標識，用於鑑定節點在通道中是什麼節點與服務。
PS：
成員服務
成員服務是爲了對身份進行授權，這一塊涉及了PKI以及MSP，PKI包含了數字證書、公鑰私鑰、證書頒發機構、廢棄證書列表。這一部分相對是密碼學的東西，不過還是比較簡單，這裏不多說，總之就是對於信任的機構開出的身份認證證書進行驗證，實現一個身份識別的作用，但是僅有PKI是不夠的，就像有很多支付方式：支付寶、銀聯、微信，但是這個平臺支持什麼支付方式是有限制的，MSP就是這個功能，MSP支持了本地以及頻道MSP：頻道就是我們所說的通道，對於每一個通道應該是私密的，因此這一部分的驗證是有必要的，而本地MSP則是對對等節點進行驗證，例如組織成員的身份驗證。這基本都是密碼學的驗證系統，這裏不多述。
鏈碼服務
這裏也不多述，簡單介紹一下執行流程：客戶端提交提案，包含了鏈碼函數以及調用函數，以proto消息發送到背書節點，背書節點調用SHIM包創建鏈碼仿真執行內容，然後初始化內容，調用參數，基於讀取和寫入的Key生成讀寫操作集，背書集羣節點模擬提案執行（讀寫等操作），如果執行結果返回成功，就執行背書，如果失敗，返回錯誤碼，背書節點對交易結果簽名，返回客戶端，如下圖：
