深度探索區塊鏈/超級帳本系統架構(3)

《深度探索區塊鏈》

1。企業級區塊鏈系統中常見的模塊構成

1。Hyperledger Fabric 1.0是一種通用的區塊鏈技術，其設計目標：

利用一些成熟的技術實現分佈式帳本技術（Distributed Ledger Technology,DLT）

2。超級帳本採用模塊化架構設計，複用通用的功能模塊和接口。

3。模塊化的方法帶來了可擴展性，靈活性等優點，會減小模塊修改，升級帶來的影響，能很好地利用微服務實現區塊鏈應用系統的開發和部署。

4。Hyperledger Fabric 1.0設計以下幾個特色：

【1】。模塊插件化

不少的功能模塊（如：CA模塊，共識算法，狀態數據庫存儲，ESCC，VSCC，BCCSP等）都是可插拔的，系統提供了通用的接口和默認的實現。這知足了大多數的業務需求。這些模塊也能夠根據需求進行擴展，集成到系統中。

【2】。充分利用容器技術

不只節點使用容器做爲運行環境，鏈碼也默認運行在安全的容器中。應用程序或者外部系統不能直接操做鏈碼，必須經過背書節點提供的接口轉發給鏈碼來執行。容器給鏈碼運行提供的是安全沙箱環境，把鏈碼的環境和背書節點的環境隔離開，鏈碼存在安全問題也不會影響到背書節點。

簡略圖：

應用程序/外部系統-》背書節點（提供接口）-》鏈碼（智能合約）

【3】。可擴展性

Hyperledger Fabric 1.0在0.6版本的基礎上，對peer節點的角色進行了拆分，有背書節點（Endorser），排序服務節點（Orderer），記帳節點（Committer）等。不一樣角色的節點有不一樣的功能。節點能夠加入到不一樣的通道（channel）中，鏈碼能夠運行在不一樣的節點上，這樣能夠更好的提高並行執行的效率和吞吐量。

peer節點拆分爲：

A。背書節點(Endorser)    B。排序服務節點（Orderer）  C。記帳節點（Committer） D。其餘。

【4】。安全性

Hyperledger Fabric 1.0提供的是受權訪問的區塊鏈網絡，節點共同維護成員信息，MSP（Membership Service Provider）模塊驗證，受權了最終用戶後才能使用區塊鏈網絡的功能。多鏈和多通道的設計容易實現數據隔離，也提供了應用程序和鏈碼之間的安全通道，實現了隱私保護。

2。系統邏輯架構

Hyperledger Fabric 1.0設計的系統邏輯架構圖：

對照英文架構圖：

說明：上述Hyperledger Fabric 1.0設計的系統邏輯架構圖是從不一樣角度劃分的。

上層從應用程序角度，提供了標準的gRPC接口。

在API基礎上封裝了不一樣語言的SDK，包括：Golang，Node.js，java，Pyhon等。開發人員可利用SDK開發基於區塊鏈的應用。

區塊鏈強一致性要求，各個節點之間達成共識需較長時間，也是採用異步通訊的模式進行開發的。

事件模塊可在觸發區塊事件或鏈碼事件時，執行預先定義的回調函數。

【1】。應用程序角度（關注要素）

（一）。身份管理

用戶註冊/登陸系統--》獲取用戶註冊證書（ECert）。其餘全部操做均需與「用戶證書關聯的私鑰」進行【簽名】

消息接收方：首先：簽名驗證   -》  再進行：消息處理

網絡節點一樣會用到頒發的證書，如系統啓動和網絡節點管理等都會對用戶身份進行認證和受權。

（二）。帳本管理

受權的用戶能夠查詢帳本數據（ledger），可經過多種方式查詢：

【1】。根據區塊號查詢區塊

【2】。根據區塊哈希值查詢區塊

【3】。根據交易號查詢區塊

【4】。根據交易號查詢交易

【5】。可根據通道名稱獲取查詢到的區塊鏈信息

（三）。交易管理

帳本數據只能經過交易執行才能更新。

應用程序經過「交易管理提交交易提案（Proposal）」並獲取到「交易背書（Endorsement）」後，再給「排序服務節點提交交易」，而後「打包生成區塊」。

SDK提供接口，利用用戶證書本地生成「交易號」，「背書節點」和「記帳節點」都會校驗是否存在重複交易。

（四）。智能合約

實現「可騙程的帳本」（Programmable Ledger），經過鏈碼執行提交的交易，實現基於區塊鏈的智能合約業務邏輯。

只有智能合約才能更新帳本數據，其餘模塊是不能直接修改狀態數據（world state）的。

【2】。底層角度（關注要素）

從Hyperledger Fabric 1.0底層角度，如何實現「分佈式帳本技術」，給應用程序提供區塊鏈服務。

（一）。成員管理

MSP（Membership Service Provider）對成員管理進行了抽象。

每一個MSP都會創建一套「根信任證書」（Root of Trust Certificate）體系，

利用PKI(Public Key Infrastructure)對成員身份進行認證，驗證成員用戶提交請求的簽名。

結合Fabric-CA/第三方CA系統，提供成員註冊功能，並對成員身份證書進行管理（如：證書新增/撤銷）

註冊的證書分爲：

【1】註冊證書（ECert）：用於用戶身份

【2】交易證書（TCert）：用於交易簽名

【3】TLS證書（TLS Cert）：用於TLS傳輸

（二）。共識服務

在分佈式節點環境下，實現同一個鏈上不一樣節點區塊的一致性，且要確保區塊裏的交易有效和有序。

共識機制由3個階段完成：

【1】。客戶端向背書節點提交提案進行簽名背書（客戶端-》背書節點）

【2】。客戶端將背書後的交易提交給排序服務節點進行交易排序，生成區塊和排序服務（客戶端-》背書後的交易-》排序服務節點）

【3】。排序服務節點廣播給記帳節點驗證交易後寫入本地帳本（排序服務節點-》區塊數據-》記帳節點）

網絡節點的p2p協議採用的是基於Gossip的數據分發，以同一組織爲傳播範圍來同步數據，提高網絡傳輸效率。

（三）。鏈碼服務

智能合約的實現依賴於安全的執行環境，確保安全的執行過程和用戶數據隔離。

採用Docker管理普通鏈碼，提供安全的沙箱環境和鏡像文件倉庫。

好處：

    容易支持多種語言鏈碼，擴展性好。

不足：

    對環境要求高，佔用資源多，性能不高。實現過程也存在kubernetes,Rancher等平臺的兼容性問題。

（四）。安全和密碼服務

【1】。BCCSP（BlockChain Cryptographic Service Provider）：（是一個抽象的接口，默認實現國標算法）

          實現密鑰生成，哈希運算，簽名驗籤，加密解密等基礎功能。 

【2】。國密算法和HSM（Hardware Security Module）

3。網絡節點架構

說明：

節點是區塊鏈通訊的主體，是一個邏輯概念。

多個不一樣類型的節點可運行在同一物理服務器上。

有多種類型節點：客戶端，Peer節點，排序服務節點，CA節點。

（一）。網絡節點架構圖

說明：

主節點：表明是和排序服務節點通訊的節點。負責從排序服務節點處獲取最新的區塊並在組織內部同步。

            可強制設置主節點也可動態選舉產生。

上述節點類型：

【1】。客戶端節點

客戶端/應用程序：是最終用戶操做的實體，它必須鏈接到某一個Peer節點/排序服務節點上與區塊鏈網絡進行通訊。

客戶端 向 背書節點（Endorser）提交「交易提案」（Transaction Proposal），當收集到足夠背書後，向排序服務廣播交易，進行排序，生成區塊。

【2】。peer節點

全部的Peer節點都是記帳節點（Committer）。

主要負責：

A。驗證排序服務節點區塊裏的交易

B。維護狀態數據和帳本的副本

部分節點會執行交易並對結果進行簽名背書，充當「背書節點」的角色。

「背書節點」是動態角色，是與具體鏈碼綁定的。

每一個鏈碼在實例化時，都會設置背書策略，指定哪些節點對交易背書後纔是有效的。也只有在應用程序向它發起交易背書請求的時候纔是背書節點。其餘時候只是普通記帳節點，只負責驗證交易並記帳。

【3】。排序服務節點（Order）

A。Order接收包含背書籤名的交易，對未打包的交易進行排序生成區塊，廣播給peer節點。

B。排序服務提供的是原子廣播，保證同一個鏈上的節點接收到相同的消息，而且有相同的邏輯順序

C。排序服務的多通道（Multichannel）實現了多鏈的數據隔離，保證只有同一個鏈的peer節點才能訪問鏈上的數據，保證用戶數據的隱私。

D。排序服務可採用集中式服務，也可採用分佈式協議。可實現不一樣級別的容錯處理。

     目前正式發佈的版本只支持Apache Kafka集羣，提供交易排序的功能。

     只實現CFT（Crash Fault Tolerence，崩潰故障容錯），不支持BFT（Byzantine Fault Tolerance，拜占庭容錯）

【4】。CA節點

CA節點是Hyperledger Fabric 1.0的證書頒發機構（Certificate Authority），由服務器和客戶端組件組成。

CA節點接收客戶端註冊申請-》返回「註冊密碼」，用於用戶登陸（以便獲取身份證書）。

在區塊鏈網絡上全部的操做都會驗證用戶的身份。CA節點爲可選，可用其餘成熟的第三方CA頒發證書。

4。Hyperledger Fabric 1.0 典型交易流程

上述，假定各節點已經提早頒發好證書 & 正常啓動 & 已加入建立好的通道。

下述，介紹在已實例化的鏈碼通道上從發起一個調用交易-》最終記帳的全過程 以下所示：

（一）。建立交易提案併發送給背書節點

使用應用程序構造交易提案，SignedProposal的結構以下所示：

上述結構說明：

SignedProposal是封裝了Proposal的結構，添加了調用者的簽名信息。

背書節點會根據簽名信息驗證其是不是一個有效的消息。

Proposal由兩部分組成：

【1】消息頭

       A。通道頭（ChannelHeader）

　　      通道頭包含了與通道和鏈碼調用相關的信息。（如：在哪一個通道上調用哪一個版本的鏈碼）

            txid是應用程序本地生成的交易號，跟調用者的身份證書相關，能夠避免交易號的衝突。

            背書節點和記帳節點都會校驗是否存在重複交易。

       B。簽名頭（SignatureHeader）

            簽名頭包含了調用者的身份證書和一個隨機數，用於消息的有效性校驗。

            應用程序（構造好交易提案請求）-》選擇-》背書節點（執行&進行背書籤名）

            背書節點是鏈碼背書策略裏指定的節點。

        （有一些背書節點是離線的，其餘背書節點能夠拒絕對交易進行背書，也能夠不背書。）

        （應用程序可嘗試使用其餘可用的背書節點來知足策略）

　　  （應用程序以何種順序給背書節點發送背書請求是沒有關係的，正常狀況下背書節點執行後的結果是一致的，只有背書節點對結果的簽名不同）

【2】消息結構

（二）。背書節點模擬交易並生成背書籤名

背書節點在收到交易提案後會進行一些驗證，包括：

【1】。交易提案的格式是否正確

【2】。交易是否提交過（重複攻擊保護）

【3】。交易簽名有效（經過MSP）

【4】。交易提案的提交者在當前通道上是否已受權有寫權限

驗證經過後，「背書節點」會根據「當前帳本數據」模擬「執行鏈碼中的業務邏輯」並生成「讀寫集（RwSet）」，

其中包含「響應值」，「讀寫集」等。

在模擬執行時帳本數據不會更新-》背書節點對這些讀寫集進行簽名成爲「提案響應」（Proposal Response）-》返回給應用程序

ProposalResponse結構以下：

 

說明：

返回的ProposalResponse中包含了讀寫集，背書節點簽名，通道名稱等信息。

（三）。收集交易的背書

應用程序收到ProposalResponse-》對背書節點簽名進行驗證 （全部節點收到任何消息後都要先驗證消息合法性）

若：鏈碼只進行帳本查詢，應用程序會檢查查詢響應，但不會將交易提交給排序服務節點

若：鏈碼對帳本進行Invoke操做，則需（判斷背書策略是否知足）提交交易-》排序服務（帳本更新）

注：若應用程序沒有收集到足夠的背書就提交交易，記帳節點在提交驗證階段會發現交易不能知足背書策略，標記爲無效交易。

如何選擇背書節點？

目前fabric-sdk-go默認實現是把配置文件選項「channels.mychannel.peers」裏的節點所有添加爲背書節點，須要等待全部背書節點的背書籤名。

應用程序等待每一個背書節點執行的超時時間是經過配置文件選項「client.peer.timeout.connection」設置，配置文件示例3秒，可調整，未設置默認5秒。

（四）。構造交易請求併發送給排序服務節點

應用程序接收到全部背書節點簽名-》根據背書籤名調用SDK生成交易-》廣播給排序服務節點

生成交易過程較簡單：

      先確認全部背書節點的執行結果徹底一致，

      再交易提案，提案響應，背書籤名打包生成「交易」

交易結果以下所示：

（五）。排序服務節點以對交易進行排序並生成區塊

排序服務不讀取交易內容，若在生成交易信封內容時僞造了交易模擬執行的結果，排序服務節點也不會發現，但會在最終交易驗證階段校驗出來並標記爲無效。

排序服務要作的很簡單：

A。先是接收網絡中全部通道發出的交易信息

B。讀取交易信封Envelope.Payload.Header,.ChannelHeader.Channelid以獲取通道名稱

C。按各個通道上交易的接收時間順序對交易信息進行排序，生成區塊

詳細流程參見第4章《基於Gossip的P2P數據分發》

（六）。排序服務節點以廣播給組織的主節點

排序服務節點生成區塊後會廣播給通道上不一樣組織的主節點。

主節點：表明的是和排序服務節點通訊的節點。負責從排序服務節點處獲取最新的區塊並在組織內同步。

（可強強制設置主節點，也可動態選舉產生）

詳細流程參見第6章《集成共識機制的排序服務》

（七）。記帳節點驗證區塊內容並寫入區塊

背書節點是動態角色，只要參與交易的背書就是背書節點。

  -》哪些交易選擇哪些節點做爲背書節點是由應用程序選擇的，這須要知足背書策略才能生效。

全部背書節點都屬於記帳節點。

全部peer節點都是記帳節點，記錄的是節點已加入通道的帳本數據。

記帳節點：

【1】接收到的是「排序服務節點生成的區塊」

【2】驗證區塊交易的有效性

【3】提交到本地帳本後再產生一個生成區塊的事件

【4】監聽區塊事件的應用程序能夠進行後續的處理

若接收到的區塊是配置區塊，則會更新緩存的配置信息。

記帳節點處理流程如圖所示：

 

說明：

【1】。交易數據的驗證

      區塊數據的驗證是以「交易驗證」爲單位，

　　每次對區塊進行驗證時都會生成一個交易號的位圖TxValidationFlags，它記錄每一個交易號的交易驗證狀態，只有狀態爲TxValidationCode_VALID纔有效。

      位圖也會寫入到區塊的元數據BlockMetadataIndex_TRANSACTIONS_FILTER中

交易驗證會檢查以下內容：

A。是否爲合法的交易：交易格式是否正確，是否有合法簽名，交易內容是否被篡改。

B。記帳節點是否加入了這個通道

上述基本驗證經過後，提交給VSCC進行背書策略驗證。

【2】。記帳節點與VSCC

鏈碼的交易是隔離的，每一個交易的模擬執行結果集TxRwSet都包含了交易所屬的鏈碼。

爲了不錯誤地更新鏈碼交易數據，在交易提交給系統鏈碼VSCC驗證交易內容前，還會對鏈碼進行校驗。

如下交易都是非法的：

【3】基於狀態數據的驗證和MVCC檢查

交易經過VSCC檢查後，進入「記帳流程」

kvledger還會對讀寫集TxRwSet進行MVCC（Multi-Version Concurrency Control）檢查

kvledger實現的是基於鍵值對（key-value）的狀態數據模型，對狀態數據鍵有3種操做：

A。讀狀態數據

B。寫狀態數據

C。刪除狀態數據

對狀態數據讀操做有2種形式：

A。基於單一鍵的讀取

B。基於鍵範圍的讀取

【4】無效的交易處理

（八）。在組織內部同步最新的區塊

詳細流程參見第4章《基於Gossip的P2P數據分發》

5。消息協議結構

（一）。信封消息結構

信封消息是認證內容中最基本的單元。

它由一個消息負載（Payload）和一個簽名（Signature）組成。

 

（二）。配置管理結構

 

（三）。背書流程結構

【1】。交易提案結構

一個提案消息包含：

A。頭部（包含描述它的一些元數據，如：類型、調用者的身份、時間、鏈的ID、加密的隨機數）

B。不透明的負載

一個提案發送給背書節點進行背書，該提案包含：

A。頭部：能夠解組爲頭部信息

B。負載：由頭部的類型決定

C。擴展：由頭部的類型決定

 

  

【2】。提案響應結構

【3】。背書交易結構

6。策略管理和訪問控制

在Hyperledger Fabric 1.0 中，較多地方都使用策略進行管理，它是一種權限管理的方法。

包括：交易背書策略，鏈碼的實例化策略，通道管理策略等。

（一）。策略定義及其類型

   

（二）。交易背書策略

交易背書策略是對交易進行背書的規則，是跟通道和鏈碼相關的，在鏈碼實例化的時候指定。

在鏈碼調用的時候，須要從背書節點收集足夠的簽名背書，只有經過背書策略的交易纔是有效的。

這是經過應用程序和背書節點之間的交互來完成的。

【1】。交易背書策略的驗證

     

       

【2】。命令行的背書策略語法

【3】。給鏈碼指定背書策略

（三）。鏈碼實例化策略

     

（四）。通道管理策略

    

小結：

本章從邏輯結構，節點結構，典型交易流程，消息協議結構，策略管理等幾個方面介紹了Hyperledger Fabric 1.0的架構。

經過這些內容介紹，可以基本瞭解Hyperledger Fabric 1.0的設計原則和思路。