fabric知識梳理圖解

1.整體架構

 

 

 

 

 

2、交易流程

 

 

 

 

 

流程步驟：

1. 應用程序通過SDK發送請求到Peer節點（一個或多個） 即發起交易
   1. 客戶A發起交易請求：合約設置的背書策略規定所有交易需要經過兩個Peer節點的簽名背書，因此請求需要被同時發往Peer A和Peer B.
   2. 客戶端應用程序利用任意SDK（nodeJS，java，go）構造交易提案。該提案是一個調用智能合約功能函數的請求，用來確認哪些數據可以讀取或寫入賬本（即更新資產的Key/Value）。
   3. SDK將交易提案打包為可識別的格式（如gRPC上的protocol buffer），並使用用戶的加密憑證為該交易提案生成唯一的簽名。
2. peer節點（Committer節點）通過chaincode分別執行交易，但是並不將執行結果提交到本地的賬本中 （可以認為是模擬執行，交易處於掛起狀態，放置於候選池）
   1. 參與背書的peer將執行結果返回給應用程序（其中包括自身對背書結果的簽名）
   2. 背書節點（使用MSP）驗證簽名（ProcessPropsal()->preProcess()-->Verify()驗證簽名）並確定提交者是否有權執行操作（使用通道的ACL）。
   3. 背書節點將交易提案的參數作為輸入，在當前狀態數據庫上執行交易，生成包含執行返回值、讀操作集合和寫操作集合的交易結果（此時不會更新賬本），這些值的集合、背書節點的簽名和背書結果（YES / NO）作為“提案的結果”返回給SDK
   4. SDK解析這些信息判斷是否應用於后續的交易。
3. 應用程序收集背書結果並將結果提交給Ordering服務節點
   1. 應用程序（SDK）驗證背書節點簽名，並比較各節點返回的提案結果，判斷提案結果是否一致以及是否參照指定的背書策略執行。
   2. 應用程序（SDK）將交易提案和結果以消息形式廣播到排序服務(Orderers/Consenter)。交易包含讀/寫操作集合、背書節點的簽名和通道ID。
   3. 排序服務不讀取交易的詳細信息，它從整個區塊鏈網絡接收交易信息，按通道分類進行排序，並為每個通道創建包含交易的區塊。
4. Ordering服務節點執行共識過程並生成block，通過消息通道發布給Peer節點（所有節點包括committer, submitter, endorser），由peer節點各自驗證交易並提交到本地的ledger中（包括state狀態的變化）
   1. 排序服務將區塊發送到通道上的所有節點，所有交易需要被驗證，確保滿足背書策略
   2. 同時，需要確保全部讀操作集合在交易生成之后，賬本上的狀態值沒有改變。
   3. 經過驗證，區塊中的交易會被標記為有效或無效，通過Event通知客戶端
5. 所有節點賬本更新
   1. 所有通道上的區塊鏈節點將新區塊加入區塊鏈，並且對於所有有效的交易，將寫操作集合提交更新到狀態數據庫中。
   2. 節點通過事件(Event)通知客戶端交易是否已被加入區塊鏈、以及交易是否有效。

問題1：committer 如何驗證區塊提交交易的有效性？

           —— 驗證交易讀寫集中的讀集（剛剛讀取到的）、世界狀態、之前未被提交的寫集（模擬交易過程）的狀態是否一致。

問題2：Fabric中的MSP的作用是什么？

         ——Fabric中的MSP可以理解為賬號，是根據PKI規范生成的一組證書和秘鑰文件。Fabric中的組織、節點、用戶都擁有各自的MSP賬號信息，這種機制的好處是可以保證網絡中的用戶數量是可控的並且用戶都是被授權的。fabric基於這樣的MSP賬號體系保證了網絡中的每條交易都有發起人的數字簽名，而且背書節點也會在交易中加入自己的簽名，保證了交易過程的清晰透明，不可篡改。

      Fabric中的orderer、peer、客戶端等操作都需要使用MSP賬號。比如：啟動orderer節點、啟動peer節點、創建通道、部署鏈碼、調用鏈碼、peer向orderer發送請求。

3、多通道

 

 

 

 

 

4、賬戶存儲

 

 

5、智能合約交互

 

 

6、應用開發模型

 

 

7、節點說明

peer節點包括：Endorse（背書節點）、Anchor（錨節點）、Leader（leader節點）、commit（提交節點）。背書節點負責背書策略，提交節點負責數據的提交。

首先所有的peer節點都是committer（記賬節點），而又有可能擔任的角色有endorser（背書節點）、Leader（主節點）、Anchor（錨節點）。

Committer

記賬節點使用基於Gossip的p2p數據分發，節點會定期跟其他節點交換信息。如果在這個過程中有節點發生故障，則會從存活的節點中刪除這個節點的信息。對於故障節點，還會定時檢查是否已經恢復，恢復存活的節點會更新到存活節點列表中。如果有新加入的節點，也能通過節點信息的交換獲取到，添加到存活列表中，廣播給其他節點。由於超級賬本采用基於反熵的狀態同步，每個節點周期性的和鄰居節點交換保存的數據，然后對比本地數據和鄰居節點所保存的數據，檢查是否有缺失或者過期的數據，然后更新本地節點的數據為最新的數據，因此故障的節點重新連接到網絡時會自動恢復數據。這些都能通過Gossip協議學習到，自動調整網絡的拓撲結構，適應網絡節點的變化，保證整個網絡正常運行。並且協議能正確工作的概率不會因為錯誤數超過f（可靠的廣播協議中存在一個f，錯誤數超過這個值就會出現異常，協議的可靠性等於不超過f個錯誤的概率）時就快速地降低。（優雅降級）

Leader

主節點連接到排序服務，負責把接受到的批量區塊轉發給其他節點。因此主節點與排序服務的穩定連接至關重要。可以強制設置為主節點，也可以動態選舉產生。主節點選舉的用處是，判斷在相同的組織中哪個節點可以作為代表連接排序服務。選舉過程在Gossip層實現，一個節點啟動的時候它先等網絡穩定再開始參與主節點選舉，一次主節點選舉的有效時間是10s。這樣可以有效避免強制設置主節點出現的發生故障無法分發區塊的問題。

Endorser

背書節點為動態的角色與具體的chaincode綁定，背書節點的故障對網絡的影響取決於chaincode對應的背書策略，例如背書策略指定只要3個組織其中的2個組織的成員完成背書，該交易就是有效的，那么只有一個組織的成員節點出現故障對交易完成沒有影響。

Anchor

錨節點是在一個channel上可以被所有其他peer發現的peer，channel上的每個成員都有一個anchor Peer(或多個anchor peer 來防止單點故障)，允許屬於不同成員的peer發現channel上的所有現有peer。錨節點的配置文件可以通過configtxgen工具生成。

 

 

錨節點負責組織之間通信，如上圖。

 

 

Leader節點負責與order節點通信，如上圖。

8、網絡拓補結構

 

 

9、數據庫

 

 

賬本由區塊鏈和狀態數據庫兩部分組成。
區塊鏈是一組不可更改的有序的區塊（數據塊），記錄着全部交易的日志。每個區塊中包含若干個交易的數據，不同區塊所包含的交易數量可以不同。區塊之間用哈希鏈（Hashed-link）關聯：每個區塊頭包含該區塊所有交易的哈希值以及上一個區塊頭的哈希值。鏈式結構可以確保每個區塊的數據不可更改以及每個區塊之間的順序關系不可更改。因此，區塊鏈的區塊只可以添加在鏈的尾部。
狀態數據庫記錄了賬本中所有鍵值對的當前值，相當於對當前賬本的交易日志做了索引。鏈碼執行交易的時候需要讀取賬本的當前狀態，從狀態數據庫可以迅速獲取鍵值的最新狀態。
如果沒有狀態數據庫，要獲得某個鍵值時，需要遍歷整個區塊鏈中和該鍵值相關的交易，效率非常低，因此，讀取狀態數據庫可以認為是快速定位和訪問某個鍵值的方法。另外，當狀態數據庫出現故障的時候，可以通過遍歷賬本重新生成。
當一個區塊附加到區塊鏈尾部的時候，如果區塊中的有效交易修改了鍵值對，則會在狀態數據庫中作相應的更新，確保區塊鏈和狀態數據庫始終保持一致。
區塊鏈的數據塊以文件形式保存在各個節點中。狀態數據庫可以是各種鍵值數據庫，Fabric缺省使用LevelDB ，也支持CouchDB的選項。CouchDB除了支持鍵值數據外，也支持JSON格式的文檔模型，能夠做復雜的查詢。

 

轉載 https://blog.csdn.net/weixin_42117918/article/details/85230754