一、系統架構
fabric系統架構由 應用程式層 和 底層區塊鏈層構成，
fabric為應用程式提供了 grpc介面，針對不同語言封裝了不同的sdk（go、nodejs、Java）
應用程式與底層互動的媒介有4個 身份、賬本、交易和智能合約
- 1.身份服務
由fabric的成員服務提供，用pka體系和ca系統提供注冊登錄及身份認證功能，這里的冊登錄不是賬號密碼那種，也不需要在區塊鏈上為每一個應用程式建立一個身份，有點像資料庫的身份管理，這個身份是應用程式用來與fabric網路進行互動的，fabric里的一個身份有多個證書， 有用戶證書、交易證書、tls證書（用戶加密傳輸）這些證書都在crypto-config檔案夾下可以看到， - 2.賬本管理
實際上是對區塊的管理，有兩種查詢方法 按區塊高度 或 按區塊哈希查詢，賬本會根據通道進行隔離，包括物理上分檔案夾存盤，
注：可以用交易id查詢區塊不太好理解， - 3.交易
應用程式提交交易到背書節點進行背書（有點擔保的意思）然后給排序節點進行排序并打包成區塊之后分發 - 4.智能合約
相當于函式定義，交易則是函式呼叫，
cap原理一致性、可用性、磁區容忍性、farbic為了提高可用性和磁區容忍性降低了一致性，fabric為了滿足一致性提出了共識機制，
fabric的共識 應用程式向背書節點提出交易請求，背書節點進行交易模擬確認交易并背書然后把背書結果和簽名回傳給應用程式，應用程式再將背書后的交易發送給排序節點進行排序并生成區塊向全網的記賬節點進行廣播，記賬節點會對交易進行再次確認，認證后再存入本地賬本，
fabric網路里有兩種通信方式 排序節點與每個組織的錨節點用grpc 組織的錨節點與其他節點之間用gossip協議完成交易廣播.
鏈碼服務 通過容器實作，不是很理想，環境所占的空間比較大，
國內的應用程式必須要采用國密，橢圓曲線和SHA256都不被認可，
二、fabric中的節點：
-
1.客戶端節點 cli
介于應用程式和底層之間并不能算是底層節點，運行時需要與orderer、peer節點建立連接才可以發揮作用 例：連接到orderer節點進行通道創建，與peer節點連接進行交易模擬等 -
2.peer節點 peer
包括anchor節點、endorser節點、 committer節點
anchor節點一個組織只有一個anchor節點（錨節點，一個組織內唯一的一個與orderer節點進行通信的節點，初始化組織的時候進行指定，系統運行中錨節點掛掉之后會自動選出一個新的錨節點與orderer連接）
endorser節點（背書節點，擔保節點，每個智能合約安裝時都會設定背書策略即由哪些節點擔保后這筆交易才有效，只有背書節點才會運行智能合約）
committer節點 （記賬節點，最基本的peer節點從某種意義來說每個節點都有記賬功能都是committer節點，如果一個節點既不是錨節點也不是背書節點那么他就是普通的記賬節點）驗證從orderer節點收到的區塊及交易的有效性，驗證過后記錄到本地的賬本中，如果交易有效還會同時更改區塊鏈的狀態資料，這三種節點并不沖突， -
3.orderer節點 orderer
排序節點，從全網的客戶端節點接受交易，將交易排序，按固定時間間隔將排序好的交易打包成區塊分發給其他組織的主節點 目前有兩種排序方式 solo單機只有一個排序節點只適用于測驗 Kafka集群排序 -
4.ca節點 ca
證書頒發機構，主要用于建立一個區塊鏈的身份，判斷一個身份是否是有效合法的，只有ca認可的機構才能夠在區塊鏈上進行交易 ca節點可以選擇，
三、fabric的網路拓撲結構
-
1.客戶端節點（基于區塊鏈的應用程式）向ca機構（可以是官方的也可能是非官方的）表明身份獲得證書用于后續的操作
-
2.客戶端可以向不同組織的背書節點發送交易提案，獲得背書后在向orderer節點提交交易
-
3.orderer節點向上提交給Kafka集群，由orderer和kafka集群完成排序后orderer向每個組織的錨節點廣播，
-
4.錨節點再在組織內通過gossip協議擴散區塊訊息，
這里存在一個樹形結構：
Kafka->orderer->anchor(錨節點）->所有的peer節點
樹形結構的好處：假如每個組織對應一個企業那么內部資料可以只在組織內部傳播，對外只需要暴露出一個anchor錨節點即可，保證了資料的安全性，
注：每個組織都有一個ca的根證書，網路中的ca節點的根證書要被其他組織所認可
四、fabric網路中的交易流程
（文中序號與圖中標號不對應）
-
1.應用程式在本地構造交易提案并向背書節點發送交易提案（這里背書節點是智能合約中的背書策略規定的，例如，智能合約的背書策略要求至少兩個背書節點背書那么客戶端就需要把交易提案發送到至少兩個背書節點，如果沒有獲得結果就繼續發送，否則交易無效，這里面的背書節點的順序沒有要求）
-
2.背書節點模擬執行交易提案并簽名，背書節點收到交易提案后會進行檢查作業如格式、是否已經提交過、簽名及發送節點是否有權限等，驗證通過后背書節點會把交易發送給智能合約隔離執行，執行完后背書節點對結果簽名（背書）并回傳給應用程式，這里只是模擬執行，不會產生持久化操作，
-
3.應用程式（客戶端節點）收到回傳的結果，首先對結果進行驗證主要是簽名，驗證通過后，如果是查詢交易，回傳結果就是需要的內容，如果是寫交易應用程式需要收到足夠多的背書結果（智能合約的背書策略規定的），然后把交易提案、背書結果和自己的簽名（稱為交易），把交易發送給排序節點orderer進行排序，
-
4.排序節點收到交易對交易排序，排序節點收到交易后首先驗證背書結果是否一致，如果不一致排序節點也發現不了（之后會有檢測），依然會按照交易提交的順序對交易排序然后打包發送給各個組織的主節點anchor
-
5.主節點驗證、保存區塊，主節點收到區塊后會首先驗證區塊里的每筆交易是否有效，無效交易會標記為無效交易（當前版本里不會洗掉，依然會保存到賬本里但不會更新狀態資料庫）
-
6.主節點在組織內通過gossip協議向各個peer節點同步區塊，每個peer節點都會像主節點一樣驗證區塊里的每筆交易是否有效并更新狀態資料庫
五、fabric中的共識
（這里只是簡單介紹共識）
所謂共識：一般指三個程序
交易背書（模擬 與endorser（背書節點）節點相關）
交易排序（排序 與orderer（排序節點）相關）
交易驗證（驗證 與committer（記賬節點）相關）
這里面共識主要指交易排序
orderer節點功能 交易排序、 區塊分發、 通道隔離
- 1.交易排序：保證系統交易順序的一致性，現階段有兩種solo和kafka
- 2.區塊分發：排序節點排完序后會把交易打包成區塊，這個區塊是中間區塊（包括所有收到的交易）各個peer節點收到區塊后還要對區塊里的每筆交易進行驗證，驗證完后會把無效交易標出來
- 3.通道隔離：交易按通道進行排序，在客戶端提交交易時會標出交易要發往的通道，orderer節點收到交易后會根據這個通道對交易分別進行排序，然后發往通道中各個組織的的錨節點，一個組織的各節點可以訂閱多個通道，通道與通道之間是隔離的，彼此之間不知道對方的存在，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/300040.html
標籤：區塊鏈