Hyperledger Fabric 整理體系：
?區塊鏈是一種按照時間順序將數據區塊以順序相連的方式組合成的一種鏈式數據結構。
?賬本在FileSystem中保存，世界狀態保存在LevelDB中。
Fabric核心概念
- chaincode：鏈碼/智能合約，對外提供調用指令。分為系統鏈碼、用戶鏈碼
- 系統鏈碼
負責fabric節點自身的處理邏輯，包括系統配置、背書、校驗等工作。系統鏈碼僅支持go語言，在Peer節點啟動時會自動完成注冊和部署。
系統鏈碼共有五種類型：- 配置系統鏈碼（CSCC）：Configuration System Chaincode，負責處理Peer端的channel配置
- 生命周期系統鏈碼（LSCC）：Lifecycle System Chaincode，負責對用戶鏈碼生命周期進行管理
- 查詢系統鏈碼（QSCC）：Query System Chaincode，提供賬本查詢API。如獲取區塊和交易等信息。
- 背書管理系統鏈碼（ESCC）：Endorsement System Chaincode，負責背書（簽名）過程，并可以支持對背書策略進行管理。
對提交的交易提案的模擬運行結果進行簽名，之后創建響應消息返回給客戶端 - 驗證系統鏈碼（VSCC）：Validation System Chaincode，處理交易的驗證，包括檢查背書策略已經多版本并發控制。
- 用戶鏈碼
根據不同場景需求及成員指定的相關規則，操作區塊鏈分布式賬本的狀態的業務處理邏輯代碼，運行在鏈碼容器中，通過fabric提供的接口與賬本狀態進行交互。在整個程序中處于重要位置，下可對賬本數據進行操作，上可以對企業級應用程序提供調用接口。
- 系統鏈碼
- transaction：tx 交易，每條指令都是一次交易
- world state：世界狀態，
- endorse：背書，在共識機制的投票環節，背書意味著參與投票
- endorsement policy：背書策略，
- peer：組織中的節點；peer節點以區塊的形式從orderer排序服務節點接收有序狀態更新，維護狀態和賬本。fabric中Peer節點可劃分如下：
- Endorsing Peer：根據指定的策略調用智能合約，對結果進行背書，返回提案相應到客戶端
- Committing Peer：驗證數據并保存到賬本中
- Anchor Peer：跨組織通訊
- Leading Peer：做為組織內所有節點的代表連接到Orderer排序服務節點，將從排序服務節點接收到的批量區塊廣播給組織內的其他節點
- channel：通道提供了一種通訊機制，將peers和orderer連接在一起，形成一個具有保密性的通訊鏈路；將一個大網絡分割成不同私有子網，進行數據隔離
- KPI：public key infrastructure，一種遵循標準的利用公鑰加密技術為電子上午的開展提供一套安全基礎平臺的技術和規范
- MSP：Membership Service Provider，聯盟鏈證書管理，保存可信任RCA、ICA
- org：orginazation，管理合作企業的組織
Fabric分層
?fabric大致分為底層網絡層、權限管理模塊、區塊鏈應用模塊。通過SDK和CLI對應該開發者提供服務。
?與此相對應的人員分為三類：
- 底層：系統運維，負責系統的部署和服務
- 組織骨干力人員：負責證書，MSP權限管理，共識機制等
-
業務開發人員：編寫chaincode，創建/維護channel，執行transaction等
fabric技術人員分層
?開發流程主要包括編寫智能合約、通過SDK調用智能合約、及訂閱各類事件。
開發環節
MSP
?每個管理協作企業的ORG組織都可以擁有自己的MSP，如圖所示：
?MSP出現在兩個地方
- 全局MSP：存在channel上，邏輯上認為是配置在系統上的，實際每一個參與者上拷貝一份
-
局部MSP：每個peer，orderer，client等角色都維護，只保存全局MSP的子集，內容保存在本地文件系統上
MSP分類
?MSP結構包含RCA根證書、ICA中間證書、OU組織單位、管理員證書、RCL吊銷證書列表、節點上的具體證書、存儲私鑰的keystore、TLS的根證書與中間證書
MSP結構
fabric交易流程
1. peer結點的部署
?peer結點上保存有賬本ledger和chaincode
?channel是一個邏輯概念，可以管理多個peer
?當有多方參與者時
?加入MSP時，可以通過MSP隔離全網不同組織的參與者
2. 交易執行流程
?去中心化的設計，必須需要通過投票（多數大于少數）來維持數據一致性，fabric具體操作如下：
- 由client端的CLI或者SDK進行proposal議案提出。client會依據chaincode中的endorsement policy決定把proposal發往哪些endorse peer；背書節點進行投票，client匯總背書節點結果
- client將獲得多數同意的proposal，連同各節點的背書及結果提交到orderring service；orderer匯總各client遞交過來的請求后，不需要檢查交易中的具體數據，只是把接收的所有通道交易，按時間順序進行排序，并創建交易區塊。
-
orderer將交易打包成區塊block，然后廣播給同一通道內所有組織的Leader節點；各節點各自驗證結果，最后將block記錄到自己的ledger中。
交易流程 - 原理
交易流程 - 編程
?從編程的角度來看，流程更清晰，A是應用程序
- A首先連接到peer
- A調用chaincode發起proposal；與此同時，P1收到后先模擬執行，產生結果放回給A
- A收到各peer返回的結果
- A向O1發起交易；與此同時，O1產生block后會通知peer，而peer會更新其賬本
-
最后通過調閱事件A收到了結果。
交易流程 - 節點
2.1 proposal議案階段
?A1發出<T1, P>，收到了<T1, R1, E1> <T1, R2, E2>兩個結果
2.2 package打包階段
?O1會在channal上收到很多transaction，將tx排序，在達到block的最大大小（一般應配1M一下，否則性能下降嚴重）或者達到超時事件后，達成block P2
2.3 驗證階段
?O1將含有多條tx打包成區塊的B2發往各peer，而P1和P2將B2加到自己的賬本中。
資料整理
