簡介
由於比特幣的流行，以太坊和一些別的衍生技術成長起來，對一些有創新力的企業開始關注區塊鏈底層技術，分佈式賬本和分佈式應用平臺。然而，許多企業需要更高的性能，這是那些無須許可的區塊鏈技術無法達到的。另外，在許多場景下，參與者的身份認證是一個核心訴求，例如金融領域
對於企業使用，有如下比較需求：
- 參與者的身份是明確的，可識別的
- 進入網絡是必須被許可的
- 較高的性能，併發
- 事務確認的低延遲
- 適用於商業場景私有的和保密的事務
基於此，Hyperledger Fabric應運而生。Hyperledger Fabric 是一個開源的企業級需要許可的分佈式賬本技術平臺。Fabric是一個高度模塊化和可配置架構。同時，Fabric的智能合約是第一個支持所有通用編程語言，例如Java, Go and Node.js。
Hyperledger Fabric還支持可插拔的共識協議，用戶可以根據自己的用例和模型進行選擇。
模塊化
- ordering 可插拔建立共識的服務，將多個不同的事務以確定的順序打包成一個區塊，然後廣播這個區塊到其他peers。
可採用不同的共識機制，目前支持Kafka，BFT-SMaRt和Solo。Kafka是基於ZooKeeper的Paxos實現，可以實現50%的CFT，不能容忍不誠實的節點；BFT-SMaRt則是PBFT的實現，可以實現33%的BFT；Solo是單order節點的ordering，主要用於開發測試。
- CA 單獨的服務，用於用戶身份識別
- Smart contracts (“chaincode”) 運行在隔離的容器環境中(Docker),可以使用不同的通用語言編寫，但是不能直接訪問賬本狀態
- endorse peer 可以單獨的爲每個應用程序配置不同的驗證策略
- Committer：負責維護區塊鏈和賬本結構（包括狀態DB、歷史DB、索引DB等）。該節點會定期地從Orderer獲取排序後的批量交易區塊結構，對這些交易進行落盤前的最終檢查（包括交易消息結構、簽名完整性、是否重複、讀寫集合版本是否匹配等）
order-execute architecture
大部分區塊鏈（也包括公鏈）所採用的流程是：將transactions排序打包然後同步到每個節點（通常採用廣播的方式），每個節點再按順序執行（或者稱之爲驗證）這些交易。在論文中，這種架構被稱之爲“order-execute architecture”，即先“order”再“execute”。
這樣的架構存在一些問題，
首先所有節點按照順序執行交易會限制性能（例如TPS），通常將不相關的操作併發執行可以提升性能，但是對智能合約很難做到併發，因爲代碼之間的依賴關係很難確定。此外，order-execute最大的限制是，所有節點所執行的交易必須滿足確定性（must be deterministic）。類似以太坊這樣採用Solidity這樣的編程語言可以一定程度上保證代碼確定性，但對於更流行的語言（例如Go，Java，C/C++），則很難保證確定性（比如Go中的map iterator就無法保證確定性）。
在聯盟鏈中，一種可行的做法是，僅讓部分節點運行代碼，然後同步最終狀態（state）至全網。這樣子一方面通過選擇運行代碼的節點從而保證代碼運行的一致性，並且減少了驗證節點數也提升了性能。
Execute-order-validate architecture
- 執行一個事務，然後校驗正確性, 從而爲它背書
- 通過可插拔的共識協議來背書
- 在提交到賬本之前，根據應用程序指定的背書策略來校驗事務
在上述架構中，智能合約這種分佈式應用包括了兩個部分：
chaincode：即原來的smart contract code，在execute階段可以運行，值得注意的是，還有一種特殊的system chaincodes，這類chaincodes定義了整個鏈的底層設置，包括validation system chaincode和endorsement system chaincode
endorsement policy：可以理解爲獨立於共識模塊的一種驗證或者背書機制。傳統consensus包括了驗證節點是否作惡以及交易本身是否正確兩個任務，而在Fabric中，將後者抽離成爲endorsement policy。實際上這個模塊也是可以替換的，比如“五個endorser節點中只要有三個執行結果一致則完成驗證”這種策略完全可以換成“只需要XXX endorser節點完成執行則通過驗證”。
- Clients：這類節點即發起交易或者調用智能合約的普通節點；
- Peers：執行驗證交易的節點，這類節點需要有全量ledger數據，在這類節點中，只有一部分負責執行交易，即endorsing
- peers（或者叫endorsers）； OSNs（Ordering Service Nodes）：
詳細的交易流程
-
client發起交易，首先將交易信息（propose message）發給定義好的若干endorsers，注意此處的endorsers是由交易本身的chaincode和其中的 endorsement policy共同決定；此處propose message包括信息如下：
tx=<clientID, chaincodeID, txPayload, timestamp, clientSig>
clientID:提交交易的client的ID
chaincodeID：交易所屬的chaincode的ID
txPayload：交易本體信息
timestamp：時間戳
clientSig：client簽名 -
endorser收到message後，用client公鑰驗證clientSig，然後運行交易並驗證輸出結果。如果該endorser被選擇爲背書節點，則把結果發回給提交的client；
-
該client收集每個endorser返回的信息，當滿足endorsement policy後，則進入ordering階段，反之該交易失敗；
-
client將通過endorsement的交易廣播至所有orderers（表示爲broadcast(tx)），後者通過某種共識機制對所有通過endorsement的交易進行排序，保證所有節點的數據滿足時序一致性；
-
orderers再將排序後的交易廣播至其他peers（包括了endorsing peers和non-endorsing peers），這裏廣播的實際上就是一個包含了若干交易的block和一個sequence number；
-
所有peers驗證block之後，更新自身的ledger，即完成上鍊。
當然上述流程中有一些較強的假設，比如對於P2P傳輸而言，需要滿足liveness，即broadcast(tx)操作在有限的時間內一定可以到達所有其他節點。
應用程序和節點（Applications and Peers）
https://hyperledger-fabric.readthedocs.io/en/latest/txflow.html
對等節點和排序節點一起工作來確保賬本在每個節點中都保持最新。在這個例子中，應用程序 A 連接到 P1 並調用 chaincode S1 來查詢或更新賬單 L1。 P1 調用 S1 來生成包含查詢結果或建議賬本更新的提案響應。應用程序 A 收到提案響應，對於查詢，過程現在已完成。 O1 將整個網絡中的交易收集到塊中，並將這些交易分發給所有節點，包括P1。P1 在處理 L1 之前會先驗證交易。一旦 L1 被更新， P1 產生一個由 A 接收的事件來表示完成。
節點可以立即將查詢結果返回給應用程序，因爲滿足查詢所需的所有信息都位於節點的賬單本地副本中。節點不會諮詢其他節點，以便將查詢返回給應用程序。但是，應用程序可以連接到一個或多個節點來發出查詢 —— 例如以證實多個對等節點之間的結果，或者如果懷疑信息可能過期，則從不同的節點檢索更新結果。在圖中，您可以看到分類賬查詢是一個簡單的三步過程。
更新事務與查詢事務比較相似，但有兩個額外的步驟。雖然賬本更新應用程序也連接到節點以調用 chaincode，與賬單查詢應用程序不同，單個節點無法執行賬單更新，因爲其他節點必須首先同意這種操作 —— 這就是共識的過程。因此，節點嚮應用程序返回更新提議 —— 這個節點將先獲得其他節點的同意。第一個額外的步驟 —— 也即第四步 —— 要求應用程序發送一組適當的更新提議到整個節點網絡中，該交易需要被整個網絡節點所同意。這是通過應用程序使用 排序節點將事務打包進區塊 來實現的，並將它們分發到節點的整個網絡，以便在應用到每個節點的賬本副本之前，可以對其進行驗證。由於整個共識處理需要一些時間才能完成（秒），因此應用程序會異步通知，如步驟5所