fabric知識梳理圖解

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

 

1.總體架構

 

二、交易流程

 

流程步驟：

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

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

問題2：Fabric中的MSP的做用是什麼？

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

      Fabric中的orderer、peer、客戶端等操做都須要使用MSP帳號。好比：啓動orderer節點、啓動peer節點、建立通道、部署鏈碼、調用鏈碼、peer向orderer發送請求。

三、多通道

 

四、帳戶存儲

五、智能合約交互

六、應用開發模型

七、節點說明
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節點通訊，如上圖。

八、網絡拓補結構

九、數據庫

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