超全總結Hyperledger Fabric架構原理

Hyperledger Fabric概述

Hyperledger Fabric是由IBM公司主導開發的一個面向企業級客戶的開源項目。與比特幣和以太坊這類公有鏈不同，Hyperledger Fabric網絡中的節點必須經過授權認證後才能加入，從而避免了POW資源開銷，大幅提高了交易處理效率，滿足企業級應用對處理性能的訴求。同時，爲了滿足靈活多變的應用場景，Hyperledger Fabric採用了高度模塊化的系統設計理念，將權限認證模塊（MSP）、共識服務模塊（Ordering Service）、背書模塊（Endorsing peers）、區塊提交模塊（committing peers）等進行分離部署，使開發者可以根據具體的業務場景替換模塊，實現了模塊的插件式管理（plug-in/plug-out）。所以，Hyperledger Fabric是一個私有鏈／聯盟鏈的開發框架，而且系統的運行不需要token支持。

基本概念

Ledger：賬本，節點維護的區塊鏈和狀態數據庫
World state：世界狀態，經過數次交易後最新的鍵值對，世界狀態是一個數據庫，存儲的是賬本當前值。作用是能夠快速獲取賬本最新值而不必根據交易日誌從頭開始計算。世界狀態中還有一個屬性——版本號，版本號從0開始，每當狀態更新時版本號就遞增。狀態更新時會首先檢查版本號，以確保當前狀態的版本與背書時的版本一致（避免併發更新）。
Channel: 通道，私有的子網絡，通道中的節點共同維護賬本，實現數據的隔離和保密。每個channel對應一個賬本，由加入該channel的peer維護，一個peer可以加入多個channel，維護多個賬本。
Org：Orginazation，管理一系列成員的組織。一個channel內可以有多個組織。
Chaincode：鏈碼(智能合約)，運行在節點內的程序，提供業務邏輯接口，對賬本進行查詢或更新
Endorse：背書，指一個節點執行了一個交易並對結果進行簽名後返回響應的過程。
Ordering Service：排序服務，將交易排序後放入區塊中，並廣播給網絡各節點
PKI：Public Key Infrastructure，一種遵循標準的利用公鑰加密技術爲電子商務的開展提供一套安全基礎平臺的技術和規範
MSP：Membership Service Provider，成員管理服務，基於PKI實現，爲網絡成員生成證書，並管理身份

Fabric v0.6和v1.x架構差異

節點：在Fabric v1.x中把節點分爲peer節點（維護state和ledger）,Order節點（負責共識或者排序賬本中的交易）和背書節點（負責執行交易和鏈碼）而在Fabric v0.6中則沒有這些概念，只有一個peer節點，peer節點同時完成上述所有的功能。

這樣設計的優勢

鏈碼（Chaincode）執行信任的可伸縮性，將用戶自己開發的鏈碼和系統提供的Order服務拆分，用戶開發的鏈碼和系統提供的Order服務不再是一一對應的關係，Order也可以適當容忍錯誤的出現，增強了系統的魯棒性。
可擴展性，拆分鏈碼和Order的串行執行，在原有架構中，當鏈碼執行非常耗時的時候，Order將會處於閒置狀態，不利於提高系統的吞吐量，拆分以後鏈碼和order可以並行執行。
共識機制可以單獨實現（Order）。

Hyperledger Fabric Network的共識算法

在所有peers中，交易信息必須按照一致的順序寫入賬本（區塊鏈的基本原則）。例如，比特幣通過POW機制，由最先完成數學難題的節點決定本次區塊中的信息順序，並廣播給全網所有節點，以此來達成賬本的共識。而Hyperledger Fabric採用了更加靈活、高效的共識算法，以適應企業場景下，對高TPS的要求。目前，Hyperledger Fabric有三種交易排序算法可以選擇。

SOLO：只有一個order服務節點負責接收交易信息並排序，這是最簡單的一種排序算法，一般用在實驗室測試環境中。Sole屬於中心化的處理方式。

Kafka：是Apache的一個開源項目，主要提供分佈式的消息處理／分發服務，每個kafka集羣由多個服務節點組成。Hyperledger Fabric利用kafka對交易信息進行排序處理，提供高吞吐、低延時的處理能力，並且在集羣內部支持節點故障容錯。

SBFT：簡單拜占庭算法，相比於kafka，提供更加可靠的排序算法，包括容忍節點故障以及一定數量的惡意節點。目前，Hyperledger Fabric社區正在開發該算法。

各種節點

節點（peer）是區塊鏈的通信實體，是一個邏輯概念，不同類型的多個節點可以運行在同一個物理服務器上。節點主要有以下四種：

客戶端節點

客戶端必須連接到某一個peer節點或排序服務節點上才能與區塊鏈網絡進行通信。客戶端向背書節點（endorser）提交交易提案（transaction proposal），當收集到足夠背書後，向排序服務廣播交易提案，進行排序，生成區塊。

普通節點peer

peer節點根據所承擔的角色又可以分爲記賬節點（committer）、背書節點（endorser）、主節點（leader）和錨節點（anchor）。

記賬節點：所有的peer節點都是記賬節點（committer），負責驗證排序服務節點區塊裏的交易，維護狀態和總賬（Ledger）的副本。該節點會定期從orderer節點獲取包含交易的區塊，在對這些區塊進行核發驗證之後，會把這些區塊加入到區塊鏈中。committer節點無法通過配置文件配置，需要在當前客戶端或者命令行發起交易請求的時候手動指定相關的committer節點。記賬節點可以有多個。
背書節點：部分節點還會執行交易並對結果進行簽名背書，充當背書節點（endorser）的角色。背書節點是動態的角色，是與具體鏈碼綁定的。每個鏈碼在實例化的時候都會設置背書策略，指定哪些節點對交易背書後交易纔是有效的。並且只有應用程序向它發起交易背書請求的時候纔是背書節點，其他時候都是普通的記賬節點，只負責驗證交易並記賬。背書節點也無法通過配置文件指定，而是由發起交易請求的客戶端指定。背書節點可以有多個。
主節點：peer節點還可以是主節點（leader peer），能與排序服務節點通信，負責從排序服務節點獲取最新的區塊並在組織內部同步。主節點在整個組織中只能有一個。
錨節點：peer節點還可以是錨節點（anchor peer），錨節點主要負責代表組織和其他組織進行信息交換。每個組織都有一個錨節點，錨節點對於組織來說非常重要，如果錨節點出現問題，當前組織就會與其他組織失去聯繫。錨節點的配置信息是在configtxgen模塊的配置文件configtx.yaml中配置的。錨節點只能有一個。

排序服務節點orderer

接收包含背書籤名的交易，對未打包的交易進行排序生成區塊，廣播給peer節點。排序服務提供的是原子廣播，保證同一個鏈上的節點接收到相同的信息，並且有相同的邏輯順序。

CA節點

fabric1.0的證書頒發機構，由服務器和客戶端組成。CA節點接收客戶端的註冊申請，返回註冊密碼用於用戶登錄，以便獲取身份證書。區塊鏈上的所有操作都需要驗證用戶身份。

原文鏈接：https://blog.csdn.net/ASN_forever/article/details/86538915

交易流程

以下是fabric的經典交易流程，所有涉及到對賬本數據更新的操作都是基於這個交易流程來完成的。

1.發送交易提案

客戶端發送交易提案（Proposal）到背書節點（peer節點），提案中包含交易所需參數。

2.模擬執行交易提案

背書節點會調用鏈碼模擬執行交易提案(Proposal)，這些執行不會更新賬本。

每個執行都會產生對狀態數據讀出和寫入的數據集合，叫做讀寫集（RWsets），讀寫集是交易中記錄的主要內容。

3.返回提案響應

背書節點會對讀寫集進行背書(Endorse)簽名，生成提案響應(Proposal response)並返回給應用程序。

4.交易排序

應用程序根據接收到的提案響應生成交易，併發送給排序服務節==（Order節點）==。排序服務打包一組交易到一個區塊後，分發給各記賬節點。

5.交易驗證並提交

每個節點會對區塊中的所有交易進行驗證，包括驗證背書策略以及版本衝突驗證（防止雙花），驗證不通過的交易會被標記會無效（Invalid）。

賬本更新：節點將讀寫集更新到狀態數據庫，將區塊提交到區塊鏈上。

6.通知交易結果給客戶端

各記賬節點通知應用程序交易的成功與否，交易完成。

在Fabric v1.0中，僅在網絡上發送簽名和讀寫集，所以可伸縮性和性能得到了優化，因爲只有背書者和提交者能看到交易，所以整個網絡所需要的信任更低，提供了更高的安全性。

每個ChainCode在部署時，都需要和背書（ESCC）和驗證（VSCC）的系統ChainCode關聯。

ESCC決定如何對proposal進⾏背書。

VSCC決定事務的有效性（包括背書的正確性）。

交易有兩種類型

鏈碼的部署是通過一個帶參數的交易來進行的，當執行成功則一個鏈碼被部署到區塊鏈上
調用部署好的鏈碼修改相應的狀態並且返回
即兩種，部署交易（deploy transaction）和調用交易（invoke transaction）。

blockchain數據結構

狀態（State）

區塊鏈最新的未被持久化的狀態是帶版本號的鍵值對（KVS），這些狀態被智能合約通過put，get方法操作，並且會被日誌記錄，如果有其他的RDBMS解決方案都可以靈活的替換。

智能合約可以根據key的名字來識別是屬於哪個智能合約，原則上一個合約可以讀取所有屬於它自身的所有key。跨合約交易（cross-transactions）修改state目前還不支持，屬於v1後續版本。

賬本（Ledger）

賬本提供了所有state成功修改和對state不成功修改的嘗試的記錄。

賬本通過order把所有有效和無效的交易構建了一個完全有序的鏈，而其中的每一個block中的交易又是完全有序的，這樣就保證了所有交易的有序性。

賬本保存在Peer或者可以保存在order的子集中，二者唯一的區別是Peer中保存的賬本可以通過bitmask來區分交易的有效性。

Ledger允許重做所有transactions的歷史記錄，並且重建state。

fabric系統邏輯結構圖

通道channel

fabric的數據存儲結構被設計成多賬本體系，每個賬本在fabric中被稱爲channel。每個channel中都有一個完全獨立的賬本。同一個channel中的所有peer節點都保存一份相同的數據。

通道是兩個或多個特定網絡成員之間進行通信的專用“子網”，用於進行私有和機密事務。通道由成員（組織）、每個成員的錨節點、賬本、鏈碼應用程序和排序服務節點定義。網絡上的每個交易都是在一個通道上執行的，在該通道上，每一方都必須經過身份驗證和授權才能在該通道上進行交易。加入通道的每一個peer都有其自己的身份，由成員服務提供者（MSP）提供。

爲通道上的每個成員選擇主節點，用於代表該成員與排序服務進行通信。算法會自動選出主節點。共識服務對交易進行排序打包成區塊，並把區塊它發送給主節點。然後主節點根據gossip協議將區塊分發給通道中的成員。

儘管一個錨節點可以屬於多個通道，因此能夠維護多個賬本，但是任何賬本數據都不能從一個通道傳遞到另一個通道。這種用通道對賬本進行隔離的方式是由配置鏈碼、成員身份服務和gossip數據分發協議共同定義和實現的。通道上只有具備驗證成員資格功能的節點纔有權限進行數據分發。這種將peers和賬本數據進行通道隔離的方式使得網絡成員能夠在同一個區塊鏈中進行私密交易（只有自己通道的成員才知道交易信息）。

https://zhuanlan.zhihu.com/p/55341714
https://zhuanlan.zhihu.com/p/38289914

網絡及配置

網絡則主要包括兩大部分：用戶證書和鏈碼。

接口主要是fabric sdk，比如fabric java sdk和fabric node sdk。

網絡基礎配置=證書+yaml文件

網絡的基本單元是容器，網絡是由一個個的容器組成的，如peer容器，orderer容器等。其中，容器是由yaml文件和證書兩部分組成的。

yaml文件和docker聯繫緊密，所以你需要掌握docker的使用方法。yaml文件描述了peer的配置，而peer是網絡的重要組成部分，所以如何實現動態的增加用戶(peer\user)，還得需要使用kubernates進行管理。

在用戶證書這部分，由於官方1.1版本的的例子中使用的是cryptogen二進制工具，意思就是說官方1.1版本的例子只能安裝事前配置的用戶的數量生成相應數量的用戶證書，所以沒法實現動態生成peer\user證書從而動態增加用戶(peer\user)。於是出現了fabric-ca，fabric-ca即是解決這樣的需求的。通過使用fabric-ca動態生成證書，你將對fabric證書體系的理解更上一個層次。

在網絡配置上運行着的是鏈碼
就好像電線架好了，電就可以傳輸了一樣，基礎網絡配置好了後，那在網絡上運行着的便是鏈碼了。

在fabric中鏈碼和peer是獨立的容器，因此你可以獨立編輯的你的鏈碼文件，只要實現了規定的鏈碼接口，那麼你這個鏈碼便可以在peer上運行了，現在鏈碼文件大都是go語言實現的。