Hyperledger Fabric技術框架詳解

買賣虛擬貨幣
在上一堂課的學習中,我們介紹了Hyperledger Fabric的基情況以及組成,今天我們來拆解其架構組成,細說Hyperledger Fabric的技術框架。Fabric模組-成員服務區塊鏈網路中的每一個參與者(包括客戶端應用程式,記賬節點、排序服務節點等),要想參與區塊鏈網路,都必須具有封裝在X.509數字證書中的數字身份。這些身份非常重要,因為它們確定了參與者在區塊鏈網路中對資源的訪問許可權。要使身份可以驗證,它必須來自可信任的權威機構。成員服務提供商( MSP)在Fabric中就充當權威機構的角色,預設使用X.509證書作為身份,採用傳統的公鑰基礎結構(PKI)分層模型。PKI(Public Key Infrastructure,公鑰基礎設施)的目標就是實現不同成員在不見面的情況下進行安全通訊(建立信任),Fabric採用的模型是基於可信的第三方機構,也就是證書頒發機構(Certification Authority,CA)簽發的證書。CA會在確認申請者的身份後簽發證書,同時會線上提供其所簽發證書的最新吊銷資訊,這樣使用者就可以驗證證書是否仍然有效。證書是一個包含公鑰、申請者相關資訊以及數字簽名的檔案。數字簽名保證了證書中的內容不能被任何攻擊者篡改,而且驗證演算法可以發現任何偽造的數字簽名。通常情況下,PKI體系包含證書頒佈機構(CA)、序號產生器構(RA)、證書資料庫和證書儲存實體。
· RA是一個信任實體,它負責對使用者進行身份驗證以及對資料、證書或者其他用於支援使用者請求的材料進行合法性審查。

· CA則會根據RA的建議,給指定使用者頒發數字證書,這些證書由根CA直接或分層進行認證。

對上圖中的實體進行進一步介紹說明:

· Root Certificate Authority(Root CA):根CA,代表PKI體系中信任的實體,同時也是PKI體系結構中的最頂層認證機構。

· Registration Authority(RA):序號產生器構,是一個可信任的實體,透過它可以確定希望參與許可區塊鏈的使用者的有效性和身份資訊。它透過與使用者進行帶外通訊的方式以驗證使用者的身份和角色。同時RA還需要負責建立註冊所需的註冊憑證。

· EnrollmentCertificateAuthority(ECA):在驗證使用者提供的註冊憑證後,ECA負責發出註冊證書(ECerts)。

· TransactionCertificateAuthority(TCA):在驗證使用者提供的註冊憑證後,TCA負責發出交易證書(TCerts)。

· TLS Certificate Authority (TLS-CA):負責頒發TLS(Transport Layer Security,傳輸層安全協議)證書和憑據,以允許使用者使用其網路。

· Enrollment Certificates(ECerts):ECerts是長期證書,針對所有角色頒發。

· TransactionCertificates(TCerts):TCerts是每個交易的短期證書。它們是由TCA根據授權的使用者請求頒發的。此外,TCerts可以被配置為不攜帶使用者身份的資訊。它們使得使用者不僅可以匿名地參與系統,還可以防止事務的可連結性。

· TLS-Certificates(TLS-Certs):TLS-Certs攜帶其所有者的身份,用於系統和元件之間進行通訊及維護網路級安全性。

· CodeSignerCertificates(CodeSignerCerts):負責對程式碼進行數字簽名來標識軟體來源及軟體開發者的真實身份,以此保證程式碼在簽名之後不被惡意篡改。

具體的使用者註冊流程做一個簡單的介紹,成員的註冊分為兩個過程:

離線過程

· 每個使用者或者Peer節點必須向RA序號產生器構提供身份證件(ID證明),同時這個流程必須透過帶外資料(out-of-band,OOB)進行傳輸,以提供RA為使用者建立(和儲存)賬戶所需的證據。

· RA序號產生器構返回使用者有關的使用者名稱和密碼,以及信任錨(包含TLS-CA Cert)。如果使用者可以訪問本地客戶端,那麼客戶端可以將TLS-CA證書作為信任錨的一種方式。

線上過程

· 使用者連線客戶端以請求登入系統,在這一過程中,使用者將使用者名稱和密碼傳送給客戶端。
· 使用者端接著代表使用者向成員服務傳送請求,成員服務接受請求。
· 成員服務將包含幾個證書的包傳送給客戶端。
· 一旦客戶端驗證完成所有的加密材料是正確有效的,它就會將證書儲存於本地資料庫中並通知使用者,使用者註冊完成。

現在來看看這些身份如何用於表示區塊鏈網路的可信成員。這是會員服務提供商(MSP)發揮作用的地方:它透過列出其成員的身份來識別應該信任哪些根CA和中間CA是信任域的成員,或者哪些CA被授權為成員簽發有效的身份。

MSP的強大不僅僅是列出誰是網路參與者或頻道成員。MSP可以在它所代表的組織範圍內識別參與者可能扮演的特殊角色,為網路和通道的訪問許可權設定奠定基礎。在區塊鏈網路中,有兩個地方會出現MSP,一個是本地MSP,一個是通道MSP。

· 本地MSP用來定義節點和使用者的許可權,定義了本地層面的成員哪些有管理權哪些有參與權。

· 如果一個組織的節點想要加入某個通道,那麼本地MSP也要加入通道的配置中,一個通道中的所有節點共享通道MSP的檢視。下面來看一個例子。

使用者B的身份由RCA1簽發,儲存在本地MSP中,當B想要連線到Peer並嘗試在peer上安裝智慧合約時,需要執行一下操作:

· Peer先檢查ORG1-MSP,以驗證B的身份確實是ORG1的成員。驗證成功後將允許install命令實現鏈碼的安裝。
· B希望在通道上也例項化智慧合約,那麼通道上的所有組織必須都同意。因此,Peer必須先檢查通道的MSP,然後才能成功提交此命令。

本地MSP僅在應用的節點或使用者的檔案系統上定義。因此,在物理上和邏輯上,每個節點或使用者只有一個本地MSP。

由於通道MSP可用於通道中的所有節點,因此它們在通道配置中進行邏輯定義一次。其實,通道MSP也在通道中為每個節點的檔案系統例項化,並透過一致性保持同步。

Fabric模組-區塊鏈服務

Fabric的區塊鏈服務包含4個模組:共識管理、分散式賬本、賬本儲存以及P2P網路協議。

· 共識管理用於在多個節點的分散式複雜網路中使訊息達成共識。
· 分散式賬本與賬本儲存負責管理區塊鏈系統中所有的資料儲存,比如交易資訊、世界狀態等。
· P2P網路協議則是網路中節點的通訊方式,負責Fabric中各節點間的通訊與互動。

1. P2P網路

在Fabric的網路環境中,節點是區塊鏈的通訊實體.存在三類不同的節點,分別是客戶端節 點(Client)、Peer節點(Peer)以及共識服務節點(Ordering Service Nodes或者Orderers).

客戶端節點代表著終端使用者實體

· 必須連線到Peer節點後才可以與區塊鏈進行通訊互動。
· 可以根據它自己的選擇來連線到任意的Peer節點上,建立交易和呼叫交易。
· 在實際系統執行環境中,客戶端負責與Peer節點通訊提交實際交易呼叫,與共識服務通訊請求廣播交易的任務。

Peer節點負責與共識服務節點通訊來進行世界狀態的維護和更新

· 它們會收到共識服務廣播的訊息,以區塊的形式接收排序好的交易資訊,然後更新和維護本地的世界狀態與賬本。

· Peer節點可以額外地擔當背書節點的角色,負責為交易背書。每個合約程式碼程式都可以指定一個包含多個背書節點集合的背書策略。

2. 共識服務

Fabric網路中的Orderers節點聚集在一起形成了共識服務

· 它可以看作一個提供交付保證的通訊組織。
· 共識服務為客戶端和Peer節點提供了一個共享的通訊通道,還為包含交易的訊息提供了一個廣 播服務的功能。

共識服務可以有不同的實現方式,在v1.0版本中,Fabric將共識服務設計成了可插拔模組,可以根據不同的應用場景配置不同的共識選項。目前,Fabric提供了3種模式實現:Solo、Kafka和Ratf。

· Solo是一種部署在單個節點上的簡單時序服務,它只支援單鏈和單通道。

· Kafka是一種支援多通道分割槽的叢集共識服務,可以支援CFT(Crash Faluts Tolerance)。它容忍部分節點宕機失效,但是不能容忍惡意節點。

· Raft遵循“領導者和追隨者”模型,每個通道都選舉一個“領導者”,它的決定將被複制給“追隨者”。只要總節點數與失效節點數目滿足n>=2f+1,它就允許包括領導者在內的部分節點宕機失效。

3. 分散式賬本

區塊鏈技術從其底層構造上分析,可以將其定義為一種共享賬本技術。賬本是區塊鏈的核心組成部分,在區塊鏈的賬本中,儲存了所有的歷史交易和狀態改變記錄。

· 在Fabric中,每個通道都對應著一個共享賬本,而每個連線在共享賬本上的Peer節點,都能參與網路和檢視賬本資訊,即它允許網路中的所有節點參與和檢視賬本資訊。

· 賬本上的資訊是公開共享的,並且在每個peer節點上,都維持著一份賬本的副本。

Fabric模組-合約程式碼服務

Fabric合約程式碼服務提供了一種安全且輕量級的方式,沙箱驗證節點上的合約程式碼執行,提供安全容器服務以及安全的合約程式碼註冊服務。

其執行環境是一個鎖定和安全的容器,合約程式碼首先會被編譯成一個獨立的應用程式,執行於隔離的Docker容器中。在合約程式碼部署時,將會自動生成一組帶有簽名的智慧合約的Docker基礎映象。在Docker容器中,Peer節點與合約程式碼互動過程如圖所示:

步驟如下:

· Peer節點收到客戶端發來的合約程式碼執行請求後,透過gRPC與合約程式碼互動,傳送一個合約程式碼訊息物件給對應的合約程式碼。

· 合約程式碼透過呼叫Invoke()方法,執行getState()操作和putState()操作,向Peer節點獲取賬本狀態資料庫和傳送賬本預提交狀態數。若要讀取和寫入私有資料,則透過getPrivateDate()和putPrivateDate()方法。

· 合約程式碼執行成功後將輸出結果傳送給Peer節點,背書節點對輸入和輸出資訊進行背書籤名,完成後應答給客戶端。

圖學院第三單元的課程今天就結束啦!感謝同學們的一路陪伴~大家也要記得複習哦!從下一期我們將進入新的篇章,敬請期待啦~

免責聲明:

  1. 本文版權歸原作者所有,僅代表作者本人觀點,不代表鏈報觀點或立場。
  2. 如發現文章、圖片等侵權行爲,侵權責任將由作者本人承擔。
  3. 鏈報僅提供相關項目信息,不構成任何投資建議

推荐阅读

;